Improve Environment Variable & Secret Redaction Behavior in Wrangler CLI

[dimilau]

Problem Statement

Currently, wrangler dev unexpectedly hides plain environment variable values when they are overridden in .dev.vars / .env, even when they are not secrets. Additionally, build logs during Cloudflare Worker deployments do not list configured secrets.

Current Behavior vs. Issue

Environment / Context	Configuration	Observed Output	Issue / Ambiguity
Local Dev (wrangler dev)	Variable defined in wrangler.toml only	env.MY_VAR ("100900")	Works as expected.
Local Dev (wrangler dev)	Variable defined in both wrangler.toml AND .dev.vars / .env	env.MY_VAR ("(hidden)")	Unexpected: Value is hidden even though it is a standard local environment variable, not a secret.
Worker Deployment Build	Secrets bound to the Worker	(Secrets not listed)	Secrets attached to the Worker environment are omitted from build output logs entirely.

Proposed Solution & Expected Behavior

We propose refining how Wrangler handles string visibility in output logs for both local development and deployment builds.

1. Local Development (wrangler dev)

Scenario A: Standard Setup (No secrets key in configuration file)

• Overridden Environment Variables: If a variable is present in both wrangler.toml and .dev.vars / .env, Wrangler should display the active value from .dev.vars / .env rather than hiding it.
• Fallback Unbound Variables: If a variable is defined in .dev.vars / .env but not declared in wrangler.toml, treat it as a potential secret and display (hidden).

Scenario B: Explicit secrets Schema (If secrets config property is defined)

• Overridden Environment Variables: If a variable is defined in both wrangler.toml and .dev.vars / .env, show the resolved value from .dev.vars / .env.
• Required Secrets: If a key is explicitly declared under the secrets configuration property (e.g., set as required), mark it clearly as (hidden secret) during local execution.

2. Cloudflare Worker Deployment Build

When running deployment builds, Wrangler should list all secrets attached to the target Worker environment in the binding output summary, explicitly masking their values:

Your Worker has access to the following bindings:
Binding								Resource
env.MY\_VARIABLE\_A("10900")		Environment Variable 
env.MY\_SECRET\_KEY(hidden secret)	Secret

Comparison Matrix (Expected Output)

Variable Source	Defined in wrangler.toml	Defined in .dev.vars	Defined in secrets Config	Expected wrangler dev Output
Standard Env Var	Yes	No	No	env.MY_VAR ("<value_from_toml>")
Overridden Env Var	Yes	Yes	No	env.MY_VAR ("<value_from_dev_vars>")
Undeclared Local Var	No	Yes	No	env.MY_VAR ("(hidden)")
Explicit Secret	Optional	Optional	Yes (Required)	env.MY_VAR ("(hidden secret)")

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

Summary

Feature request to change how wrangler dev displays variable values (showing the resolved value instead of (hidden) when a wrangler.toml/wrangler.json var is overridden in .dev.vars/.env), and to list configured secrets in deployment build logs.

Classification

• Type: Feature Request
• Component: packages/wrangler
• Severity: Low
• Has Reproduction: N/A (feature request; behavior clearly described with a before/after table)
• Quality: Complete

Findings

• Created: not readable from truncated context (single-line JSON exceeded the read limit)
• Author: dimilau (Dimi Lau), human reporter
• Version: not specified
• Labels: not readable from truncated context
• Comments: not readable from truncated context

Analysis

• The issue is a well-structured enhancement proposal ("We propose refining how Wrangler handles string visibility…"), not a bug report — it describes desired behavior rather than a defect blocking usage.
• Two distinct asks: (1) in wrangler dev, when a plain var from wrangler.toml/wrangler.json is also present in .dev.vars/.env, show the resolved value rather than (hidden); (2) surface configured secrets in Worker deployment build logs.
• Clearly maps to packages/wrangler — it concerns wrangler dev local variable/secret resolution and deployment output logging.
• The proposal includes nuanced scenarios (with/without an explicit secrets schema, overridden vs. fallback/unbound variables), so any implementation should be careful not to leak actual secret values into logs — treating unknown/undeclared .dev.vars entries as (hidden) is the right conservative default.
• Does not match any Step 2 closure category (not spam, not resolved, not a duplicate reference within the issue, not wrong-repo, not stale on the readable evidence, not user error). It is a legitimate, actionable enhancement.

Recommendation

Status: KEEP OPEN

Reasoning: This is a clear, well-motivated feature request scoped to wrangler dev output and deployment build logs, both of which live in packages/wrangler. It does not match any close criteria and describes a reasonable UX improvement with defined scenarios.

Action: Triage to the Wrangler team for a product decision. Confirm whether showing resolved override values (rather than (hidden)) is desirable, since it changes what appears in dev output and has secret-leakage considerations. If accepted, scope work in packages/wrangler for the dev variable-resolution logging and deployment build log output.

Suggested Labels: none applied automatically — confirm existing repo labels before adding (candidates: an "enhancement"/feature-request label and a wrangler package label if they exist).

Suggested Comment

Thanks for the detailed proposal! To make sure we scope this correctly, a couple of clarifications would help:

• For the wrangler dev change: are you primarily interested in seeing the resolved value only for variables explicitly declared as plain vars in your config (and overridden by .dev.vars/.env), while anything not declared in config stays (hidden)? We want to avoid accidentally printing real secret values to the terminal.
• For the deployment build logs: which command/output are you looking at (e.g. wrangler deploy), and would listing just the secret names (not values) meet your need?

This is a reasonable local-dev UX improvement, so we'll leave it open for the team to consider.

Structured summary (JSON)

{
  "issueNumber": 15167,
  "title": "wrangler dev hides overridden plain env var values and deployment build logs omit configured secrets",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15167",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "Well-structured, actionable feature request scoped to packages/wrangler covering wrangler dev variable display and deployment build log output. It does not match any close criteria.",
  "suggestedAction": "Triage to the Wrangler team for a product decision on showing resolved override values vs. (hidden), and on listing secret names in deployment build logs; implement in packages/wrangler if accepted.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[workers-devprod]

• Reproduction: ⚠️ Blocked. Sandbox became unresponsive during pnpm build needed to run Wrangler tests. Located relevant tests encoding reported behavior but could not execute them.