CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC treats value "0" as enabled — presence-based, ignores value; silently blocks Remote Control
Summary
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC appears to be evaluated by presence, not value. Setting it to "0" (or presumably false/empty) still disables non-essential traffic, which in turn blocks Remote Control. A user who writes "0" reasonably expects "not disabled," but gets the opposite.
Environment
- Claude Code 2.1.220 (VS Code extension native binary), macOS arm64 (Darwin 25.5.0)
- Auth: claude.ai OAuth, Max;
hasUsedRemoteControl: true(feature had worked before) - Var injected via a project
.claude/settings.jsonenvblock:"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "0"
Repro
- Set
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC="0"(env or settings.jsonenvblock). - Run
claude remote-control --verbose. - Fails with:
````
Error: Remote Control requires feature-flag evaluation, which is disabled because CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set. Unset it (or run in a shell without it) to use Remote Control.
env -u CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC claude remote-control --verbose→ connects successfully.
Expected
A boolean-style env var should honor its value: 0, false, and empty should mean "not disabled." Only truthy values (1, true) should disable non-essential traffic.
Actual
Any non-unset value — including "0" — is treated as "set → disabled." The only way to enable the feature is to fully unset the variable, which is non-obvious and surprising given the explicit "0".
Note on the error message
The VS Code extension surfaces this only as a generic "Remote Control Initialization failed"; the actionable text ("... because CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set ...") is only visible via claude remote-control --verbose from a standalone terminal. Surfacing the specific reason in the extension would save significant debugging.
Related
- #73007 (/doctor reports Remote Control setup issue when the var is set intentionally)
- #71886 (var silently breaks /usage)