[Enhancement] Decouple privacy kill switches from feature availability — silent degradation hurts power users

I want to flag a pattern that keeps tripping people up — myself included — and suggest a concrete fix.

The problem

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is documented as opting out of telemetry, error reporting, feedback submission, and auto-updates. Reasonable. But it also silently disables features that have nothing to do with telemetry: /design-sync (the Claude Design connector), Projects, live-preview, and feature-flag-gated capabilities. DISABLE_TELEMETRY has the same kind of collateral damage — it knocks out the 1-hour prompt cache TTL and, on some plans, the Opus 4.6 1M model.

When these features get disabled, there is no warning, no log line, nothing. The feature just vanishes. You're left staring at a cryptic failure (or a mysteriously absent menu item) with zero indication that an environment variable you set months ago for privacy reasons is responsible.

This is not a hypothetical. I hit it myself in #69246, where a design-sync handoff from Claude Design failed because the connector was silently blocked by DISABLE_NONESSENTIAL_TRAFFIC. Others have run into the same wall from different angles: #45918 (channels feature flag blocked), #45381 (prompt cache TTL disabled by the telemetry flag), #34178 (Opus 4.6 1M model disabled), #53899 (security updates silently dropped). The root cause is always the same: unrelated functionality bundled behind a privacy kill switch, with no diagnostic output when it fires.

What I'd like to see

Three things, in order of ambition:

1. Decouple privacy opt-outs from feature availability. Telemetry, error reporting, and feedback are genuinely optional data flows — a user should be able to turn them off without losing access to product features like design-sync or prompt caching. These are different categories of network traffic, and they deserve separate controls.

1. Print a diagnostic when a feature is disabled by an environment variable. Even a single line — design-sync disabled by CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC — would save hours of debugging. Silent degradation is the worst kind: users don't know what they don't know.

1. Document the full blast radius of each privacy flag. Right now, the docs list the intended targets (telemetry, error reporting, etc.) but not the collateral ones. An explicit "this flag also disables X, Y, Z" table would at least let people make an informed tradeoff.

I understand that gating everything behind one flag is simpler to implement. But the current behavior punishes exactly the users who care enough about the product to configure it carefully — and then leaves them no breadcrumbs when things break.