Issue with "wrangler pages deploy" for new token formats

[wijionejs]

What versions & operating system are you using?

Wrangler 4.83.0
MacOS Tahoe 26.3

Please provide a link to a minimal reproduction

Can't provide a repo since it's related to secret credentials.

Describe the Bug

Hello!

I'm experiencing issues with wrangler deploy for the new token formats.
I have two cloudflare accounts, for both of them I've created API tokens, but one was created earlier and has the older format while the second one was created today. Both have identical permissions.

The tokens are used to deploy my projects to Cloudflare Pages (and for zone management), however the token with the new format fails during deployment. Has anything changed in that regard?

Please provide any relevant error logs

No response

[dario-piotrowicz]

Hi @wijionejs 🙂, thanks for the issue

Could you clarify what you mean with new token formats? is it account scoped tokens? or something else?

[petebacondarwin]

Hi @lucasbabai — thanks for the detailed report. Error code 10000 means the token wasn't recognized at all (authentication failed before any permission check), so the issue is likely with the token itself rather than its scopes or Wrangler's behaviour. A few quick diagnostics will tell us exactly what's happening.

Step 1 — Verify the token is active

curl -s "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  -H "Authorization: Bearer <YOUR_NEW_API_TOKEN>"

Expected success response:

{ "result": { "id": "...", "status": "active" }, "success": true }

If this returns "success": false with code: 10000, the token is not recognized by Cloudflare at all — independent of Wrangler. If it returns "success": true, the token is fine and the problem lies elsewhere (see Step 3).

Step 2 — Check for copy-paste artifacts

New API tokens are longer than legacy tokens and are more susceptible to truncation or hidden characters when copying from a browser or terminal. Run:

# Token length (current Cloudflare API tokens are 40 chars; newer formats may differ)
echo -n "$CLOUDFLARE_API_TOKEN" | wc -c

# First 4 characters (safe to share publicly)
echo -n "$CLOUDFLARE_API_TOKEN" | head -c 4

# Check for a trailing newline or whitespace
echo -n "$CLOUDFLARE_API_TOKEN" | cat -A | tail -c 10

If cat -A shows a $ anywhere other than the very end, or ^M (Windows line ending), the token value has hidden characters that will break authentication.

Step 3 — Confirm the token is scoped to the right account

A token that is valid but scoped to a different account will also return 10000 when used against resources on the wrong account. Run:

curl -s "https://api.cloudflare.com/client/v4/accounts/<YOUR_ACCOUNT_ID>/pages/projects" \
  -H "Authorization: Bearer <YOUR_NEW_API_TOKEN>" | jq '.errors'

If this returns code: 10000 even though Step 1 showed status: active, the token's account binding doesn't match <YOUR_ACCOUNT_ID>. In that case, please check the Account Resources section of the token in the Cloudflare dashboard — it should explicitly list your account, not "All accounts".

Step 4 — Capture a CF-Ray from the failing Wrangler deploy

A CF-Ray header is present on every response from api.cloudflare.com and lets us look up the exact edge log for your request.

To capture it:

WRANGLER_LOG=debug npx wrangler deploy 2>&1 | grep -i "cf-ray"

Or, if you can reproduce the failing request as a raw curl:

curl -si "https://api.cloudflare.com/client/v4/accounts/<YOUR_ACCOUNT_ID>/pages/projects/<YOUR_PROJECT_NAME>" \
  -H "Authorization: Bearer <YOUR_NEW_API_TOKEN>" \
  | grep -i cf-ray

Please paste the CF-Ray value here — it looks like CF-Ray: 7a1b2c3d4e5f6789-LHR.

What we expect to find

The most common causes of 10000 with a newly-created token are:

• Token not yet active (dashboard shows "Active" but takes a moment to propagate — rare)
• Token scoped to a different account than the one being deployed to
• Copy-paste artifact (hidden whitespace, truncation, smart quotes)
• Token created as a legacy Global API Key rather than a scoped API Token — these use a different authentication scheme (X-Auth-Key / X-Auth-Email) and will always fail if sent as a Bearer token

If Steps 1–3 all pass cleanly, please share the CF-Ray from Step 4 and we can trace the exact server-side rejection.

[wijionejs]

@petebacondarwin
Thanks for the detailed answer! It helped a lot. I actually found the root cause of this. My initial though was completely wrong - the problem isn't in the token format or anything like that.

While following the steps you asked, I was skimming through the logs and noticed that the command uses an incorrect account_id even though I pass CLOUDFLARE_ACCOUNT_ID as an environment variable. Since I manage multiple accounts from a single repository and the credentials are set dynamically, the account_id of the first run was cached and used for all subsequent commands even though the token applied correctly because the token isn't cached as far as I understand. In other words, there was a mismatch between the token and account id.

I'm wondering if there is a way to disable caching so that I can explicitly pass the credentials through environment variables every time I run the command? This behavior isn't obvious at all, I would expect explicit parameters to take precedence over cached values. Is this even documented anywhere?

[petebacondarwin]

I think that the CLOUDFLARE_ACCOUNT_ID env var should override any previously cached account id... It would be helpful to see a reproduction of the exact scenario for this.

[petebacondarwin]

This comment suggests that env var beats cached var:

workers-sdk/packages/wrangler/src/user/user.ts

Line 1265 in fce77a3

* Returns account_id preferentially from config.account_id > CLOUDFLARE_ACCOUNT_ID env var > cache > or user selection.

[petebacondarwin]

And the code below that appears to agree

[wijionejs]

@petebacondarwin
Here is how the projects are deployed. Both CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_API_TOKEN are passed as environment values. But unless I remove node_modules/.cache/wrangler, the old account id shown in the logs generated by wrangler and the project cannot be deployed.

spawnSync(
    "pnpm",
    [
      "--yes",
      "wrangler",
      "pages",
      "deploy",
      `./dist/${DOMAIN}`,
      `--project-name=${PROJECT_NAME}`,
    ],
    {
      stdio: "inherit",
      env: {
        ...process.env,
        CLOUDFLARE_ACCOUNT_ID: id,
        CLOUDFLARE_API_TOKEN: token
      }
    }
  );

Is there something wrong with the way I pass those credentials? I assume everything is fine as the command runs successfully after deleting cache.
Your cli.js file is quite large so I'm not sure where exactly I could add console.log to debug it, but it seems that it does take the value from cache instead of env variables, at least for me.

[petebacondarwin]

Ah of course, this is Pages deploy, not Worker deploy.

workers-sdk/packages/wrangler/src/pages/deploy.ts

Lines 186 to 190 in fce77a3

	const configCache = getConfigCache<PagesConfigCache>(
	PAGES_CONFIG_CACHE_FILENAME
	);
	const accountId = await requireAuth(configCache);

You can see here that it loads the "Pages" cache file (from pages.json) and then uses the account id from that.

This is arguably a bug in Pages deploy that should be fixed to use the env var if available first, to be the same as Workers deploy.