Repository navigation
cargo upgrade returns 401 consistently even after changing registry token #931
Description
% cargo upgrade
Checking virtual workspace's dependencies
Error: status code '401 Unauthorized': the request was not authorized
cargo upgrade --verbose dont seem to give any extra details on the error.
Tried the following:
- removing all cache
- renewing the token in
config.toml - cargo search --registry internal-registry-name internal-feature works fine with the token enabled
- other cargo commands like
cargo clean,cargo build,cargo testall work fine
This was working fine for many months and seeing this issue only the last couple months now.
Activity
epage commentedon May 1, 2025
0.13.2 fixed a bug where we were silencing network errors. Do you think that you had upgraded to that version within that time window?
shrasrir commentedon May 1, 2025
yes, have been using version > 1.84 the last few months. I upgraded it to v1.86.0 and tried running
cargo upgradebut keep getting 401 consistently.epage commentedon May 1, 2025
Note that
cargo-edits version is mostly independent of what version of Cargo you are using.shrasrir commentedon May 1, 2025
oh ok, yes I see
cargo-edit-upgrade 0.13.2shrasrir commentedon May 1, 2025
Seeing this issue only on updating cargo-edit to versions 0.13.2 or 0.13.3. Looks like 0.13.1 is the last version that doesn't see this error fyi.
anton-dutov commentedon Jun 13, 2025
@epage
After updating cargo edit to latest version, an authorization error appeared, after rolling back to 0.13.1, it works again
The error appears when using a private registry with token auth (credentials.toml)
@shrasrir Thanks, after reverting version to 0.13.1 issue is gone
pseyfert-sevensense commentedon Jun 23, 2025
chiming in:
with version 0.13.1 I get no errors BUT the private registry doesn't seem to get checked for upgrades
with newer versions, I get asked for authentication but then get the 401 errors
afaiu, the authentication is successful: I ran
rm -rf ~/.cargo/registrybeforecargo upgrade, and thecargo upgradecommand re-populated~/.cargo/registry/{cache,src}/crates-REDACTED-HASH/TL;DR:
reverting to 0.13.1 makes the 401 errors go away and
cargo upgradeexists successfully (return code 0) BUT it doesn't actually upgrade dependencies for me.MaxG87 commentedon Nov 10, 2025
I just wanted to report that I am still affected by this bug. I receive my
cargo-editthrough Arch's package repository.This leaves me unable to upgrade any dependencies using
cargo upgrade, since I depend on one crate from a private registry.azeater commentedon Apr 14, 2026
Just wanted to bump this - I'm also seeing authentication issues when trying to run
cargo upgradewith a private registry. All other cargo commands work fine (e.g. update, search etc). My version is 0.13.9.r0wdiggity commentedon May 14, 2026
cargo install cargo-edit and cargo update both worked within the same workflow, its only cargo upgrade that failed
fix: resolve registry auth tokens for cargo upgrade
fix: resolve registry auth tokens for cargo upgrade
jaques-sam-tlv commentedon Jun 18, 2026
Can this be fixed? The issue is still happening with latest version.
r0wdiggity commentedon Jun 25, 2026
i know you closed my PR because I used AI to help write it and it was too big, but it did resolve the issue, and a lot of the code was testing. If you dont want to accept my code I would ask that you look at the patterns and logic to help implement it, this is blocking us being able to use this since everything we do is private registry, but essentially, there is never an auth token passed in the current fetch, so even though it respects the private repo, it never considers auth.
sunsided commentedon Jul 13, 2026
Stepped in it just today with 0.13.11 - downgrading to 0.13.1 also fixed it for me.
It appears like the error may have existed all the time, just that after 0.13.1 we're seeing it.
fix(upgrade): Authenticate index requests to private registries
sunsided commentedon Jul 16, 2026
Prepared a partial fix for the issue in #968, unblocks registries that require a token to log in - in my case, Kellnr.