wrangler deploy --var NAME:VALUE does not override baked-in vars.NAME in config file (wrangler 4.123.0)

[AleksNeStu]

Summary

wrangler deploy --var NAME:VALUE does not override a baked-in vars.NAME value in the wrangler config file. The config-file value wins. This is reproducible on wrangler@4.123.0 (and was also present on 4.101.x as far as I traced).

Reproduction

Minimal wrangler.toml (or .jsonc):

name = "test-var-override"
main = "src/index.js"
compatibility_date = "2025-01-01"

[vars]
FOO = "from-config"

Minimal src/index.js:

export default {
  async fetch(request, env) {
    return new Response(JSON.stringify({ FOO: env.FOO }));
  }
}

Then:

npx wrangler@4.123.0 deploy --var "FOO:from-cli"
# In another shell:
curl https://test-var-override.<acct>.workers.dev
# → { "FOO": "from-config" }   <-- WRONG (config-file value won)

Expected

The CLI --var should override the config-file vars entry, just like every other wrangler config layer does. The result should be:

{ "FOO": "from-cli" }

Actual

{ "FOO": "from-config" }

This is a meaningful behavioural surprise. Users (including me) reasonably assume --var NAME:VALUE is the runtime override — it's the only way to set per-deploy values without committing a config change. The current behaviour silently discards the override, which is the worst possible failure mode for a CLI flag.

Versions tested

• wrangler@4.123.0 (latest stable as of 2026-08-14) — bug present
• wrangler@4.101.x (earlier version I worked with) — bug present
• Reproduction is config-format-agnostic (TOML and JSONC both exhibit it)

Workaround (verified working in our production deploy)

wrangler secret put NAME <<< VALUE writes to the server-side secret store, which is a different code path from vars and is not shadowed by config-file entries. The catch: secrets are encrypted at rest and intended for sensitive values, so using them for non-sensitive per-deploy values (e.g. COMMIT_SHA) is semantically wrong and incurs an extra API call per deploy. I had to switch our CI deploy from --var to secret put because the former is silently broken in this version.

Impact

Anyone using wrangler deploy --var to inject per-deploy metadata (commit SHA, deploy ID, build number, feature flags) is getting the wrong value at runtime and may not have noticed because the override value is usually similar to the config default. Worst-case: a deploy pipeline reports "deploy v1.2.3 succeeded" while the live Worker is still on the v1.2.2 value (or whatever was last hard-coded in the config).

Suggested fix

The --var parsing path should take precedence over the config-file vars entry (or at minimum the two should compose, with the CLI value winning on conflict). I haven't dug into the source, but my guess is the config-file vars block is being merged into env first and the --var argument is being applied as an additive append without overriding existing keys.

Cross-reference

Affects a production deploy pipeline built on Cloudflare Workers Static Assets. Filed from investigation of a version: "unknown" regression that we traced to this exact bug — we now use wrangler secret put as a workaround.

Happy to provide a test case in the wrangler test suite if that helps.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #15197

Summary

Reporter claims wrangler deploy --var NAME:VALUE does not override a config-file [vars] entry (the config-file value wins), but automated verification and a maintainer request for a reproduction are still outstanding.

Classification

• Type: Bug
• Component: packages/wrangler
• Severity: Medium
• Has Reproduction: No (inline steps provided, but not independently reproducible — no clonable repo)
• Quality: Partial

Findings

• Created: 2026-08-14
• Author: AleksNeStu (Alex Nesterovich)
• Version: wrangler@4.123.0 (also reported on 4.101.x)
• Labels: awaiting-response:reporter, needs-reproduction
• Comments: 3

Analysis

• The write-up is detailed (minimal wrangler.toml/.jsonc, minimal src/index.js, exact deploy --var "FOO:from-cli" command, expected vs actual output), and clearly maps to the deploy command's handling of the --var flag vs the config vars map in packages/wrangler.
• However, an automated triage run (comment by workers-devprod) could not reproduce the behavior: unit tests and local wrangler dev confirm --var does override config vars both in metadata and at runtime, because the code assigns cliVars after getBindings(config). The reported remote-deploy behavior was not reproduced.
• A maintainer (jamesopstad) followed up on 2026-08-17 asking the reporter to provide a minimal reproduction, and the issue already carries the awaiting-response:reporter and needs-reproduction labels.
• The reporter documents a working workaround (wrangler secret put, a different server-side code path), so this is not blocking.
• Because the core claim is contradicted by existing tests and local verification, and the difference (if any) is on the remote deploy path, this needs a reproducible case from the reporter before a maintainer can act. It is not closeable under any Step 2 category yet (too recent to be stale — only ~3 days old).

Recommendation

Status: NEEDS MORE INFO

Reasoning: Automated verification and local testing indicate --var already overrides config vars (CLI value assigned after config bindings), directly contradicting the report. A maintainer has already requested a minimal reproduction, and the issue is labelled needs-reproduction / awaiting-response:reporter.

Action: Wait for the reporter to supply a minimal, clonable reproduction. If no response arrives within ~30 days, this becomes a candidate for closure under the stale/no-response rule.

Suggested Labels: awaiting-response:reporter, needs-reproduction

Suggested Comment

Thanks for the detailed write-up. We tried to reproduce this and found that --var NAME:VALUE does override the config-file [vars] entry in our tests and in local wrangler dev (the CLI-supplied vars are applied after the config bindings). Because we can't reproduce the config value winning on deploy, we'd need a bit more to investigate:

• A minimal, clonable reproduction repo (config + worker + the exact wrangler deploy command) that shows the config value winning at runtime.
• Does the override work correctly in local dev (wrangler dev --var "FOO:from-cli"), or does it only fail on deploy?
• The full output of the failing wrangler deploy run (with the uploaded bindings summary), if possible.

Without a reproduction we won't be able to dig further, but as soon as you share one we're happy to take another look.

Structured summary (JSON)

{
  "issueNumber": 15197,
  "title": "wrangler deploy --var NAME:VALUE does not override baked-in vars.NAME in config file (wrangler 4.123.0)",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15197",
  "recommendation": "NEEDS MORE INFO",
  "difficulty": "medium",
  "reasoning": "Automated verification and local testing show --var already overrides config vars (CLI value applied after config bindings), contradicting the report, and a maintainer has already asked for a minimal reproduction.",
  "suggestedAction": "Wait for the reporter to provide a minimal clonable reproduction; if none arrives within ~30 days, close under the stale/no-response rule.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["awaiting-response:reporter", "needs-reproduction"]
}

[workers-devprod]

• Reproduction: ❌ Could not reproduce. Unit tests and local wrangler dev confirm --var overrides config vars in metadata and at runtime. Code assigns cliVars after getBindings(config). The reported remote deploy behavior was not reproduced in wrangler.

[jamesopstad]

Please provide a minimal reproduction.