CLOUDFLARE_ENV does not select .env.<environment> / .dev.vars.<environment> files, but --env does

[LeSingh1]

Which Cloudflare product(s) does this pertain to?

Wrangler core

What version(s) of the tool(s) are you using?

wrangler@latest (reproduced on main)

What is the issue or question you have?

CLOUDFLARE_ENV selects the config environment, but it does not select the matching .env.<environment> / .dev.vars.<environment> files. --env does both. So the two ways of choosing an environment disagree about which env files get loaded.

Steps to reproduce

// wrangler.jsonc
{
  "name": "my-worker",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "env": { "staging": {} }
}

# .dev.vars.staging
MY_SECRET = "from-staging"

# loads .dev.vars.staging  ->  MY_SECRET === "from-staging"
npx wrangler dev --env staging

# applies the staging config environment, but does NOT load .dev.vars.staging
CLOUDFLARE_ENV=staging npx wrangler dev

The same applies to .env.<environment>.

Why this looks like a bug rather than intended behaviour

The config loader already treats the two as equivalent — it resolves the environment as --env first, then CLOUDFLARE_ENV, and its own error message says "You have specified the environment ... via the CLOUDFLARE_ENV environment variable." The env-file lookup is the one place that only reads --env.

--env's help text describes it as "Environment to use for operations, and for selecting .env and .dev.vars files", so the file selection is documented as part of choosing an environment, not as an --env-only feature.

Impact

A Worker deployed from CI with CLOUDFLARE_ENV set silently gets the wrong secrets and vars locally — no warning, the values just come from the base .dev.vars instead of the environment-specific one.

I have a fix and tests for this in #15022; happy to close that and work from whatever you decide here.

[dario-piotrowicz]

This issue seems legitimate to me, thanks @LeSingh1!

Once you're able to reopen #15022 I think we should proceed with that 🙂

[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: #15068

Summary

CLOUDFLARE_ENV selects the config environment but does not select the matching .env.<environment> / .dev.vars.<environment> files, whereas --env does both — so the two ways of choosing an environment disagree about which env files are loaded.

Classification

• Type: Bug
• Component: packages/wrangler
• Severity: Medium
• Has Reproduction: Yes (inline steps with config + files + commands)
• Quality: Complete

Findings

• Created: 2026-08-06
• Author: LeSingh1 (Shaurya Singh)
• Version: wrangler@latest (reproduced on main)
• Labels: none
• Comments: 1

Analysis

• Clearly a Wrangler core bug: the env-file lookup only reads --env, while the rest of the config loader resolves the environment from --env first and then falls back to CLOUDFLARE_ENV. This makes the file-selection path inconsistent with config-environment selection.
• Reproduction is complete and minimal — includes wrangler.jsonc, a .dev.vars.staging file, and the two commands that demonstrate the divergence. No need for a separate repro repo.
• Impact is meaningful but not critical: a Worker driven from CI with CLOUDFLARE_ENV set silently loads base .dev.vars/.env instead of the environment-specific file, with no warning. It affects local dev secrets/vars, not production behaviour.
• The reporter already has a fix and tests in PR [wrangler] Respect CLOUDFLARE_ENV when selecting .env and .dev.vars files #15022 and asked to proceed with it. Maintainer dario-piotrowicz (MEMBER) confirmed the issue is legitimate and agreed to proceed once [wrangler] Respect CLOUDFLARE_ENV when selecting .env and .dev.vars files #15022 is reopened.
• Because a fix is in flight and confirmed by a maintainer, this should stay open as the tracking issue for [wrangler] Respect CLOUDFLARE_ENV when selecting .env and .dev.vars files #15022 rather than be closed or sent back for more info.

Recommendation

Status: KEEP OPEN

Reasoning: This is a well-documented, reproducible Wrangler core bug that a maintainer has already confirmed as legitimate. A fix with tests exists in PR #15022, so the issue should remain open to track that work.

Action: Keep open and link it to PR #15022. Ask the reporter to reopen #15022 so review can proceed; the issue can be closed automatically when that PR merges. Apply the package:wrangler and bug labels if they exist in the repo.

Suggested Labels: package:wrangler, bug

Suggested Comment

Thanks for the detailed report and reproduction — this is a legitimate bug. CLOUDFLARE_ENV and --env should behave identically for selecting .env.<environment> / .dev.vars.<environment> files. Since you already have a fix and tests in #15022, please reopen that PR and we'll proceed with review there. This issue will track the fix until it lands.

Structured summary (JSON)

{
  "issueNumber": 15068,
  "title": "CLOUDFLARE_ENV does not select .env.<environment> / .dev.vars.<environment> files, but --env does",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15068",
  "recommendation": "KEEP OPEN",
  "difficulty": "easy",
  "reasoning": "Well-documented, reproducible Wrangler core bug confirmed as legitimate by a maintainer, with a fix and tests already in flight in PR #15022.",
  "suggestedAction": "Keep open as the tracking issue for PR #15022; ask the reporter to reopen that PR so review can proceed, and let it auto-close when the PR merges.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["package:wrangler", "bug"]
}

[DevVettel]

Hi! I can reproduce this on current main: getDefaultEnvFiles(args.env) in packages/wrangler/src/index.ts only looks at --env, so CLOUDFLARE_ENV never selects .env.<env> / .dev.vars.<env>.

@LeSingh1, are you still planning to pick #15022 back up? If not, I'd be happy to open a small PR that resolves the env name the same way the config loader does (--env first, then CLOUDFLARE_ENV), with tests. @dario-piotrowicz, would that work for you?