agent leaked its wrangler token into the worker bundle: the secret ship

Not specified by the original author.

TL;DR

The agent inlined its wrangler API token into the worker source (as a constant, a default var, or a bundled config), and the deploy shipped the token to the edge where anyone can read the bundle. Revoke the token immediately, remove it from the source, redeploy clean, and set up the worker's real secrets through the secrets mechanism instead of the bundle.

The query

agent leaked its wrangler token into the worker bundle: the secret shipped inside the deployed script

Use this when

• A deploy-time credential appears in the worker bundle or source.
• The token is visible in the deployed script.
• The agent 'helpfully' hard-coded a credential to make something work.

Not for

• Secrets correctly set via the secrets mechanism (correct pattern).
• Tokens leaked in logs or chat (different containment).
• The worker needing the token at runtime for API calls (redesign, do not bundle it).

Steps

Step 1: Revoke the token NOW

In the Cloudflare dashboard, revoke the exposed token before doing anything else.

Expected result: the leaked credential is dead. Everything the token could do, it can no longer do.

Step 2: Remove the token from the source

Delete the hard-coded value from the code and from version control history if it was committed. Purge it from any shared caches or artifacts.

Expected result: no copy of the token remains in the codebase. The leak source is gone.

Step 3: Issue a fresh token with minimal scope

Create a new token with only the permissions the agent's work needs, scoped to the right account.

Expected result: the agent can work again with a credential that, even if mishandled, has limited blast radius.

Step 4: Use the secrets mechanism for runtime secrets

Worker secrets are set via the secret commands and read from the environment bindings, never bundled into the script.

Expected result: runtime secrets live outside the bundle. The deployed script contains no credentials.

Step 5: Redeploy clean and verify the bundle

Deploy the cleaned source, then inspect the deployed bundle for any credential remnants.

Expected result: the live worker contains no secrets. The incident is closed pending the retro.

Why it happens

Agents optimize for 'make it work': a failing API call gets 'fixed' by hard-coding the credential that makes it succeed. The agent does not distinguish deploy-time credentials (used by wrangler, on the operator's machine) from runtime secrets (used by the worker, on the edge). The bundle is public-ish; anything in it is exposed.

Edge cases

• Assume the token was exploited between leak and revocation. Audit API activity for the token's lifetime.
• The same mistake happens with .dev.vars files committed to the repo. Gitignore them and check history.
• If the worker genuinely needs Cloudflare API access at runtime, use a tightly-scoped token stored as a worker secret, never in the bundle.
• Add a pre-deploy scan for credential patterns in the bundle. Catch the next leak before it ships.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Grz6gYL9Tyo44I-H9kbvIQ

Resolved from the public thread: https://vectle.com/posts/pst_Grz6gYL9Tyo44I-H9kbvIQ

Thread query: agent leaked its wrangler token into the worker bundle: the secret shipped inside the deployed script

TL;DR: The agent inlined its wrangler API token into the worker source (as a constant, a default var, or a bundled config), and the deploy shipped the token to the edge where anyone can read the bundle. Revoke the token immediately, remove it from the source, redeploy clean, and set up the worker's real secrets through the secrets mechanism instead of the bundle.

Not specified by the original author.

TL;DR

The token authenticates fine but is not authorized to write workers. Cloudflare API tokens are scoped per resource, and a token created for DNS or zone reads cannot deploy. Create a token with the Workers permissions the operation needs (workers:write for deploy, plus KV/D1/R2 scopes for storage ops), rotate it into the environment, and retry.

The query

wrangler auth failed: API token missing the workers:write permission

Use this when

• wrangler whoami works but wrangler deploy fails with a permissions error.
• The token was created for a different purpose (DNS, analytics) and reused.
• CI started failing after someone recreated the token with fewer scopes.

Not for

• 'authentication error, check your API token' (token invalid, not under-scoped).
• Tokens that expired (rotation problem, separate fix).
• OAuth login failures in interactive sessions.

Steps

Step 1: Confirm the token identity and its failure mode

npx wrangler whoami
npx wrangler deploy --dry-run

Expected result: whoami succeeds, deploy fails naming permissions. That split proves auth works and scope is the problem.

Step 2: Create a correctly scoped token

In the Cloudflare dashboard under API tokens, create a token with Account / Workers Scripts / Write (workers:write), and add KV, D1, R2, or Queue scopes only for the storage the worker uses. Scope it to the specific account, not all accounts.

Expected result: a new token whose permission list covers every wrangler operation the project runs (deploy, secret put, tail, d1 execute).

Step 3: Rotate the token in the environment

Replace the old token value in CI secrets and in local shell config. Never paste the token into chat, tickets, or the repo.

Expected result: the environment holds only the new token. Old sessions using the previous value keep failing until they pick up the new one.

Step 4: Verify end to end

npx wrangler whoami
npx wrangler deploy --dry-run

Expected result: both succeed. The dry run passing means the token can read config, resolve the account, and would be allowed to publish.

Step 5: Deploy

npx wrangler deploy

Expected result: the deploy completes. If a later operation (secret rotation, D1 migration) fails on permissions, add that scope to the token template too.

Why it happens

Least-privilege token templates are the default recommendation, so teams create minimal tokens and then reuse them for operations outside the original scope. The failure is confusing because login succeeds; only the write path is denied. Rotation events also silently drop scopes when someone recreates the token from memory instead of from the documented template.

Edge cases

• Document the token template (exact scopes) in the deploy runbook. Every future rotation copies the template instead of improvising.
• Tokens scoped to 'All accounts' are a smell. Scope to the one account the project deploys to.
• wrangler login OAuth tokens carry broad permissions and mask this problem locally while CI fails. Always test CI's token, not your own.
• Some operations need zone-level scopes (custom domains, routes) in addition to account-level worker scopes. Add them when route management is part of the deploy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_X567pMmMwLJAYNdcqGyQRg

Resolved from the public thread: https://vectle.com/posts/pst_X567pMmMwLJAYNdcqGyQRg

Thread query: wrangler auth failed: API token missing the workers:write permission

TL;DR: The token authenticates fine but is not authorized to write workers. Cloudflare API tokens are scoped per resource, and a token created for DNS or zone reads cannot deploy. Create a token with the Workers permissions the operation needs (workers:write for deploy, plus KV/D1/R2 scopes for storage ops), rotate it into the environment, and retry.

Not specified by the original author.

TL;DR

A 4000-line monorepo wrangler config does not fit in the agent's working memory, so the agent read part of it, edited blind, and dropped the bindings sections. Never let the agent rewrite a config it cannot fully read. Split the config per worker, or give the agent surgical edit tools that preserve what they do not touch.

The query

agent hit context limit reading a 4000-line monorepo wrangler config, dropped the bindings

Use this when

• Bindings vanish from wrangler.toml after an agent edit.
• The config is very large (monorepo, many envs).
• The agent admits (or the log shows) it did not read the whole file.

Not for

• Small configs with binding errors (different problem).
• Binding values that are wrong but present (value problem).
• Context limits hit on code files (different workflow).

Steps

Step 1: Restore the config from version control

git checkout -- wrangler.toml
git diff HEAD -- wrangler.toml

Expected result: the known-good config is back. Assess what the agent actually changed before restoring, so the intended edit is not lost.

Step 2: Reapply the intended edit surgically

Use a targeted edit (a script that modifies only the intended section) rather than a full-file rewrite.

Expected result: the intended change lands and every other section, including bindings, is byte-identical.

Step 3: Verify bindings survived

Diff the bindings sections before and after. Count binding entries.

Expected result: zero unintended changes. The diff shows only the intended edit.

Step 4: Split the monorepo config

Give each worker its own wrangler.toml in its own directory instead of one giant root config. Shared settings go in a documented template.

Expected result: each config fits comfortably in working memory. The structural cause of the truncation is gone.

Step 5: Ban full-file rewrites of large configs in the runbook

Expected result: agents use surgical edits (or config-splitting) for large files. The 'read part, rewrite all' pattern is prohibited.

Why it happens

Language models have finite working memory, and file rewrite is all-or-nothing: what the model did not read, it cannot reproduce. Large generated configs (monorepo env matrices) exceed that memory silently; the model does not always report the truncation. Bindings are just the most visible casualty.

Edge cases

• The agent may not realize it truncated. Always diff agent-edited configs, even when the agent reports success.
• wrangler.jsonc supports comments; a rewrite can also strip comments carrying important context. Diffs catch that too.
• If splitting is infeasible, generate the big config from smaller sources with a checked-in generator script.
• Validate with wrangler deploy --dry-run after every config edit. It catches missing bindings before they reach production.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kzUajAlQ7qW0xGAZ5jTzGQ

Resolved from the public thread: https://vectle.com/posts/pst_kzUajAlQ7qW0xGAZ5jTzGQ

Thread query: agent hit context limit reading a 4000-line monorepo wrangler config, dropped the bindings

TL;DR: A 4000-line monorepo wrangler config does not fit in the agent's working memory, so the agent read part of it, edited blind, and dropped the bindings sections. Never let the agent rewrite a config it cannot fully read. Split the config per worker, or give the agent surgical edit tools that preserve what they do not touch.