[FEATURE] DISABLE_NONESSENTIAL_TRAFFIC silently disables security updates — unbundle DISABLE_AUTOUPDATER

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 is documented as a convenience flag for "minimizing all non-essential network traffic and background services in a single setting" (https://code.claude.com/docs/en/env-vars.md). It bundles four DISABLE_* variables — including
DISABLE_AUTOUPDATER, which means setting this flag also stops Claude Code from receiving security updates and CVE patches.

Security updates are by definition essential. Bundling them under a flag named "non-essential traffic" is a silent footgun:

• A privacy-conscious user reads the flag name, reaches for it to silence telemetry / surveys / error reports — exactly its stated purpose — and unintentionally pins their installation to whatever version was current at the moment they set it. They never opted out of

security updates, but they have effectively been opted out.

• There is no warning at the point of configuration.
• claude doctor reveals the state only after the fact, and the label it uses is the inverse of reality:

Updates
├ Auto-updates: disabled (set by env: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC)
├ Auto-update channel: stable
└ Version check skipped (essential-traffic-only mode)

• "Essential-traffic-only mode" should still permit security updates — that is the definition of essential.

Anthropic Support confirmed this behaviour on 2026-04-27 ("you are correct: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 currently disables auto-updates by bundling DISABLE_AUTOUPDATER...") and asked that this be filed as a feature request.

This is not the first time a feature has been mis-bundled under this flag: #45381 (closed/completed) and #52787 (open) are precedent issues for the same unbundling argument.

Proposed Solution

Any one of the following resolves the issue. Listed in order of preference:

1. Remove DISABLE_AUTOUPDATER from the CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC bundle. (Preferred.) Cleanest fix; aligns the bundle name with its actual contents. The flag would then bundle only the genuinely non-essential traffic (telemetry, error reporting, feedback).

Users who want to disable the auto-updater can still do so explicitly via DISABLE_AUTOUPDATER=1. This keeps the convenience flag honest.

1. Add a prominent warning in the env-var documentation and in claude doctor output that CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC also disables security updates. Specifically:

• Update https://code.claude.com/docs/en/env-vars.md to flag the security-update implication.
• Change the claude doctor line Version check skipped (essential-traffic-only mode) — the current label is misleading.

1. Introduce a separate convenience flag (e.g. CLAUDE_CODE_DISABLE_TELEMETRY_TRAFFIC) that excludes the auto-updater. Users can then opt out of analytics without giving up patches, while existing users of the current flag retain backwards-compatible behaviour.

Workaround for users hitting this in the meantime: drop CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC from the env block in ~/.claude/settings.json and set the four individual flags (DISABLE_TELEMETRY, DISABLE_ERROR_REPORTING, DISABLE_FEEDBACK_COMMAND,
CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY) directly. Auto-updates resume on next launch.

Alternative Solutions

Alternative Solution

Three further approaches I considered but rejected in favour of the proposed solutions:

1. Rename the bundle (e.g. CLAUDE_CODE_DISABLE_PHONE_HOME) without changing its contents. Honest about what it does, but doesn't solve the underlying problem that auto-updates are being treated as non-essential.
2. Interactive confirmation at first use — when Claude Code detects this flag is set, prompt the user once to confirm they understood that auto-updates are disabled. Adds friction; many users would dismiss the prompt without reading it.
3. Status quo + improved discoverability — leave the bundle as-is, but make claude doctor warn loudly. Treats the symptom, not the cause; new users still walk into the trap before they ever run claude doctor.

The proposed solutions in the previous section are preferred because they fix the design rather than warning users about it after the fact.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

A privacy-conscious user installs Claude Code on their workstation. They review available env vars, see CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, read the description ("minimize all non-essential network traffic and background services"), and decide that's exactly what
they want — they intend to silence telemetry, error reports, and feedback prompts. They set the flag in ~/.claude/settings.json:

{
"env": {
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
},
"autoUpdatesChannel": "stable"
}

Weeks later, they notice they're still on the version they originally installed and run claude doctor to investigate. The output reveals the auto-updater has been disabled all along. They had no intention of opting out of security updates; they thought the channel
setting (stable) would govern updates and the disable flag would only govern telemetry. The two settings appeared to be in different concerns. They were not.

This is the actual case I encountered (2026-04-27, Claude Code 2.1.116, native install on Linux). Anthropic Support confirmed the bundling behaviour and recommended I file this as a feature request.

Additional Context

Anthropic Support confirmation (2026-04-27):

▎ "You are correct: CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 currently disables auto-updates by bundling DISABLE_AUTOUPDATER along with telemetry, feedback, and error reporting. That means it can prevent security updates from being applied, even when a user only
▎ intended to reduce non-essential data collection."

The support agent suggested the workaround (using the four individual flags directly) and asked that the design issue be filed here.

Precedent issues — same unbundling argument applied to other features:

• #45381 (closed/completed) — Disabling telemetry also disables 1-hour prompt cache TTL. Already accepted and fixed by unbundling.
• #52787 (open) — Decouple /feedback from telemetry/nonessential-traffic env vars. Same unbundling pattern, currently pending.

The auto-updater case is more critical than either of those because the consequence is missed security patches, not missed cache TTL or feedback prompts.

Documentation reference: https://code.claude.com/docs/en/env-vars.md