Repository navigation
Dotnet paket push doesn't work #3843
Description
Describe the bug
When I try to dotnet paket push, this doesn't work:
c:\Development\lab\OriginalScaffold\dist>dotnet paket config add-token https://www.nuget.org <MYAPIKEY>
Paket version 5.241.2
Performance:
- Runtime: 372 milliseconds
c:\Development\lab\OriginalScaffold\dist>dotnet paket push OriginalScaffold.0.1.0.nupkg --verbose
Paket version 5.241.2
Pushing package OriginalScaffold.0.1.0.nupkg to https://nuget.org/api/v2/package - trial 1
No authorization found in config file.
Request failed with '403': 'https://www.nuget.org/api/v2/package'
Response body was:
Could not push OriginalScaffold.0.1.0.nupkg: Request to 'https://www.nuget.org/api/v2/package' failed with: 403 Forbidden - The specified API key is invalid, has expired, or does not have permission to access the specified package.
This what the paket.config file looks like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<credentials>
<token source="https://www.nuget.org" value="MYAPIKEY" />
</credentials>
</configuration>
When I run the command with the api-key option and supply the api key manually it works.
To Reproduce
Steps to reproduce the behavior:
- Create a new lib using the MiniScaffold template
- Add the nuget API key as is described with
paket config add-token - Create a package running thet DotnetPack target
- Try to manually publish the package after setting the key.
Expected behavior
Publishing of the package.
Activity
Fix credential lookup to ignore www. prefix mismatch for nuget.org
github-actions commentedon Aug 31, 2026
🤖 This is an automated response from Repo Assist.
I investigated this and found the root cause: the documented
paket config add-token 'https://www.nuget.org' <token>example stores the token underhttps://www.nuget.org, butpaket push(without--url) looks up credentials using the default sourcehttps://nuget.org(nowww). Because credential matching was an exact string comparison, the stored token was never found, causing push to fail with the confusing 403/invalid-API-key error reported here.I've opened a fix that normalizes the
www.prefix during credential lookup so tokens stored under eithernuget.orgorwww.nuget.orgare found regardless of which variant is used forpush/add-token. See the linked pull request for details, tests, and trade-offs.Add this agentic workflow to your repo
To install this agentic workflow, run
Merge pull request #4418 from fsprojects/repo-assist/fix-issue-3843-n…