Binary patch for Claude Code that fixes the bug where setting
DISABLE_TELEMETRY=1 silently disables ALL feature gates — blocking 1M context,
/remote-control, and every other gated feature — not just telemetry.
Tested on v2.1.76 and v2.1.77, Max 20x, macOS. Works on macOS, Linux, and Windows.
For a simpler workaround that only fixes 1M context (no patching required), see Simple Workaround below.
After patching, gated features work while all data-collection env vars
(DISABLE_TELEMETRY, DISABLE_ERROR_REPORTING, DISABLE_AUTOUPDATER, etc.)
continue to work exactly as before.
Related issues: #29580 — source code trace proving the bug | #34083 — 1M context + /remote-control blocked on Max plan | #34143 — community-confirmed root cause analysis
Prerequisites: Python 3, Git.
git clone https://gist.github.com/ahundt/158d498f07a10fec4955a70bf475a20b \
~/.claude/claude-patch-fix-disable-telemetry-blocks-1m-context-remote-controlcd ~/.claude/claude-patch-fix-disable-telemetry-blocks-1m-context-remote-controlpython3 patch_claude_binary.pypython3 patch_claude_binary.py --real-runA backup is created automatically next to the binary
(e.g., ~/.local/share/claude/versions/2.1.77.bak.20260317_160355).
/context→ should show 1000k max (not 200k)/model opus[1m]→ should succeed (not "not available for your account")/help→ should list/remote-control
python3 patch_claude_binary.py --rollback --real-runUse --rollback-list to see all backups.
If you only need 1M context (not /remote-control or other gated features), you can
bypass the client-side check with an env var — no binary patching needed.
One-time launch:
ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-6[1m] claudeMake it permanent — add to ~/.zshrc (or ~/.bashrc):
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-6[1m]/model opus[1m] is rejected client-side (s1mAccessCache), but the server
accepts it on Max 20x after the March 13 GA. Env vars are passed to the provider
as-is, skipping that check. Banner confirms Opus 4.6 (1M context).
Credit: @ln-north, who tested on v2.1.76, Max 20x, macOS. Not independently verified by this repo's author.
When Claude Code updates itself, the new binary will be unpatched. Re-patch:
cd ~/.claude/claude-patch-fix-disable-telemetry-blocks-1m-context-remote-control
python3 patch_claude_binary.py --real-runFor unknown versions the script auto-discovers function names using stable structural patterns. If auto-discovery also fails (e.g., code structure changed), it aborts with a clear error. See Adapting to Future Versions below.
| File | Purpose |
|---|---|
patch_claude_binary.py |
Apply/rollback patches. Idempotent, dry-run default, auto-backup. Supports v2.1.76 and v2.1.77 via KNOWN_VERSIONS; auto-discovers function names for newer versions. Contains an investigation methodology in the docstring for manually tracing patches in any version. |
analyze_claude_binary.py |
Investigate the binary. 15 subcommands for version detection, function extraction, call chain tracing, patch status, traffic analysis, GrowthBook/Segment SDK deep-dives, and arbitrary pattern search. Run python3 analyze_claude_binary.py all for a full dump. |
binary_patch_...bug.md |
Original patch design document with before/after code, byte offsets, JS precedence analysis, and safety design. |
README.md |
This file — quick start, patch summary, and the full investigation report below. |
Two patches are applied. All other functions are left intact so that data-collection env vars continue to work normally. Minified function names change each release; the table shows the role name and the per-version identifiers.
| Role | v2.1.76 name | v2.1.77 name | Patch | Effect |
|---|---|---|---|---|
statsig_gate |
Ai() |
hi() |
return analytics_gate() → return!1||!0 |
Statsig/GrowthBook gate lookups always proceed; decouples feature gates from analytics state |
extra_usage_check |
bf7() |
Ij7() |
return!1 → return!0 for undefined branch |
Fixes 1M race condition: undefined means "not yet loaded", not "disabled" |
telemetry_gate |
Zv() |
Cv() |
not patched | DISABLE_TELEMETRY=1 continues to disable analytics events and block Segment |
analytics_gate |
u1_() |
o1_() |
not patched | Analytics follow env var: off when DISABLE_TELEMETRY=1, on otherwise |
| Segment init | b27() |
varies | not patched | Segment follows env var: blocked when DISABLE_TELEMETRY=1, works otherwise |
feedback_gate |
L8T() |
v8T() |
not patched | Feedback surveys stay suppressed when DISABLE_TELEMETRY=1 |
Data-collection flag status (all env-controlled after patching):
| Flag | Controls | After patching |
|---|---|---|
DISABLE_TELEMETRY=1 |
Analytics events, Segment SDK | Off/blocked (env-controlled, same as before patching) |
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 |
Same as above (umbrella) | Off/blocked (env-controlled) |
DISABLE_ERROR_REPORTING=1 |
Sentry error logging | Off (env-controlled, patches don't touch this) |
CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 |
Feedback survey popup | Off (env-controlled, patches don't touch this) |
DISABLE_AUTOUPDATER=1 |
Auto-updater | Off (env-controlled, patches don't touch this) |
DISABLE_COST_WARNINGS=1 |
Cost warnings | Off (env-controlled, patches don't touch this) |
When Claude Code updates, minified function names change (e.g., Zv→Cv,
u1_→o1_). The script handles this in two ways:
Automatic (try first): For unknown versions, discover_function_names() searches
for stable structural patterns (unminified string literals that never change) and
discovers all function names automatically. If it succeeds, no manual work is needed.
Manual (if auto-discovery fails): This means the code structure changed, not just the names. To find the new functions:
- Add the new version's names to
KNOWN_VERSIONSinpatch_claude_binary.pyand re-run. TheKNOWN_VERSIONSdict maps version strings to role→name dicts. - To find those names, use
analyze_claude_binary.py searchandcontextsubcommands with stable strings that don't get minified:!!process.env.DISABLE_TELEMETRY— finds the telemetry gate functions_(process.env.CLAUDE_CODE_USE_FOUNDRY)— finds the context anchorcachedExtraUsageDisabledReason— finds the extra-usage race condition functionLKJN8LsLERHEOXkw487o7qCTFOrGPimI— finds Segment SDK inittengu_log_segment_events— finds event gate namescachedGrowthBookFeatures— finds local cache writerremoteEval:!0— finds GrowthBook instance creation
- Read the Investigation Methodology in
patch_claude_binary.py(docstring) for a step-by-step process to trace the full call chain in any version.
The Ai() patch enables Statsig/GrowthBook feature gate evaluation. This requires
network contact with Anthropic's servers even when DISABLE_TELEMETRY=1:
- GrowthBook remoteEval — sends user metadata to
api.anthropic.com:deviceId,sessionId,platform,orgUUID,accountUUID,userType,subscriptionType,rateLimitTier. No conversation content. Goes to the same server your conversations go to. - Statsig gate exposure events — Statsig's SDK logs which feature gates were evaluated for your session. These are read-only flag lookups, not usage analytics, but they are transmitted to Anthropic's Statsig instance.
This contact cannot be eliminated without also disabling feature gates entirely (which means losing 1M context, /remote-control, etc.). It is the irreducible minimum required for gated features to work.
Anthropic's data usage policy links telemetry opt-out to training data permissions.
Enabling feature gate evaluation (by applying the Ai() patch) may constitute
"allowing telemetry" in the policy sense, which could be interpreted as granting
permission for data to be used for model training.
What these patches protect:
- Client-side analytics events (Statsig usage tracking, Segment) — blocked when
DISABLE_TELEMETRY=1, via intactu1_()andb27()code paths ✓ - Sentry error reporting — blocked when
DISABLE_ERROR_REPORTING=1✓ - Feedback surveys — suppressed when
DISABLE_TELEMETRY=1via intactL8T()✓
What these patches do NOT protect:
- Feature gate evaluation network contact (GrowthBook remoteEval, Statsig gate exposure)
— enabled by the
Ai()patch. This was blocked before patching. - Server-side data retention and training policies — governed by Anthropic's ToS, not by client binary code. These patches have no effect on what Anthropic does with data that reaches their servers.
Recommendation: Review Anthropic's current data usage policy
and privacy settings in your account before applying. If the training data concern
outweighs the value of 1M context / /remote-control, do not apply the Ai() patch —
or roll it back with python3 patch_claude_binary.py --rollback --real-run.
The goal is to fix the specific structural bug (feature gates coupled to analytics state) while leaving all other code paths — especially env-var-driven data collection controls — completely intact. Every function left unpatched is one more thing that correctly respects user configuration.
Rule of thumb: find the smallest cut in the dependency graph that separates the two concerns. Do not patch downstream effects when you can cut the root coupling.
An earlier version of this patch applied 5 functions: Zv() (telemetry_gate), u1_()
(analytics_gate), Ai() (statsig_gate), b27() (Segment init), and bf7()
(extra_usage_check) — using v2.1.76 names. The intent was correct but the scope was too wide.
What went wrong:
The call chain when DISABLE_TELEMETRY=1 is (using v2.1.76 names; roles in brackets):
Zv() = true [telemetry_gate] ← reads DISABLE_TELEMETRY
→ u1_() = !Zv() = false [analytics_gate] ← analytics off ✓
→ BKK() = !Zv() = false → b27 returns null [Segment init] ← Segment blocked ✓
→ Ai() = u1_() = false [statsig_gate] → Oq() bails ← ALL feature gates: default false ✗ BUG
The bug is only in the last link: Ai() calling u1_(). To fix it, only that link
needs cutting.
The over-engineered approach instead patched Zv() to always return 0 (ignoring
DISABLE_TELEMETRY), then had to also hardcode u1_()=false (otherwise analytics
re-enabled), and hardcode b27=(0&&0) (otherwise Segment re-initialized). This
created three hardcoded outcomes that no longer respected the env vars. A user who
later removed DISABLE_TELEMETRY from their settings would still have analytics
off and Segment blocked — the binary would ignore their changed preference.
Using v2.1.76 names; roles apply to all versions:
patch: Ai() [statsig_gate] = true ← always (decouples gates from analytics)
patch: bf7() [extra_usage_check] undefined → true ← fixes 1M race condition
Zv() [telemetry_gate], u1_() [analytics_gate], b27() [Segment init], L8T() [feedback_gate]
— all intact, all env-var driven
With DISABLE_TELEMETRY=1: Zv()=true → u1_()=false (analytics off), BKK()=false
(Segment blocked), Ai()=true (gates work). All flags respected.
Without DISABLE_TELEMETRY: Zv()=false → u1_()=true (analytics on), BKK()=true
(Segment works), Ai()=true (gates work). Removing the flag fully restores original behavior.
When a new Claude Code version changes minified names, follow this process:
Step 1 — Identify the symptom precisely.
Which feature is blocked? Which env var triggers it? In this case:
DISABLE_TELEMETRY=1 → feature gates return false defaults.
Step 2 — Find the feature gate evaluation function using stable strings. Feature gate queries always call a function that returns a boolean per gate name. Search for stable patterns that won't be minified:
python3 analyze_claude_binary.py context 'cachedGrowthBookFeatures' --window 400
python3 analyze_claude_binary.py context 'remoteEval:!0' --window 400Look for the function that bails out early: if(!XYZ())return defaultValue.
XYZ() is the new name of Ai().
Step 3 — Trace what XYZ() depends on.
python3 analyze_claude_binary.py context 'function XYZ()' --window 100It will return some other function, e.g. return ABC(). That's the new u1_().
Step 4 — Trace what ABC() depends on.
python3 analyze_claude_binary.py context 'function ABC()' --window 100It should return !DEF() where DEF() is the new Zv().
Step 5 — Confirm DEF() reads the env var.
python3 analyze_claude_binary.py context 'function DEF()' --window 300You should see !!process.env.DISABLE_TELEMETRY inside it.
Step 6 — The minimal patch is always: patch XYZ() to return a constant true.
// Before:
function XYZ() { return ABC() }
// After (same byte length — adjust if names differ in length):
function XYZ() { return!1||!0 }!1||!0 = false||true = true. Same byte count as return ABC() when ABC is
a 3-character name. For 4-character names use return!0 anchored differently, or
find a same-length constant expression. Never change byte count — this corrupts the binary.
Step 7 — Verify the analytics chain is intact (not accidentally patched). After patching XYZ(), confirm:
DEF()still contains!!process.env.DISABLE_TELEMETRYABC()still returns!DEF()- Analytics senders (search for
Segment,analytics.segment.com) still checkABC()orDEF()
Step 8 — Look for the race condition pattern in any "extra usage" gate.
The bf7() pattern — undefined treated as "disabled" instead of "not yet loaded" — may
recur in future versions wherever async-loaded state is checked before the API responds.
Search for:
python3 analyze_claude_binary.py context 'cachedExtraUsageDisabledReason' --window 200If the function returns !1 (false) for void 0 (undefined), apply the same 1-byte fix:
return!1 → return!0 for the undefined branch only.
Summary of the methodology:
- Find the gate evaluation bailout function (XYZ / statsig_gate equivalent)
- Confirm it depends on the analytics/telemetry state function
- Add the new names to
KNOWN_VERSIONSinpatch_claude_binary.pyand re-run (or letdiscover_function_names()auto-discover them if structure is unchanged) - Leave everything upstream (DEF/telemetry_gate, ABC/analytics_gate, Segment init) intact
- Verify upstream chain still respects env vars
Date: 2026-03-15 Claude Code Version: 2.1.76 (latest) Plan: Claude Max Account Issues:
/model opus[1m]returns "Opus 4.6 with 1M context is not available for your account"/remote-controlis unavailable (same root cause)
Setting DISABLE_TELEMETRY=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 in ~/.claude/settings.json disables all feature-gate evaluation, not just telemetry. This means Claude Code cannot check whether the account is entitled to 1M context, /remote-control, or any other gated feature — so it defaults to false for all of them.
Note: DISABLE_ERROR_REPORTING is a separate setting (Sentry error logging) and is not present in the Pv() function based on the traced source code. It may not trigger this bug on its own, but it is commonly set alongside DISABLE_TELEMETRY and could potentially be related through a different code path not yet traced. Most users who reported the fix removed both variables simultaneously, so independent confirmation is limited.
User @Tuxerino420 traced the bug through the Claude Code source in issue #29580, comment.
Impacted file and binary:
The Claude Code CLI is distributed as a single compiled Bun executable. Platform-specific formats:
- macOS:
Mach-O 64-bit executable arm64(or x86_64) - Linux:
ELF 64-bit executable - Windows:
PE32+ executable (claude.exe)
Default binary locations:
- macOS/Linux:
~/.local/bin/claude(symlink →~/.local/share/claude/versions/<version>) - Windows:
%LOCALAPPDATA%\AnthropicClaude\app-<version>\claude.exe
The JavaScript source is bundled and minified inside this binary — there is no standalone cli.js file on disk. The npm package @anthropic-ai/claude-code exposes a single bin: claude entry point. All function names below (Pv, qA, Ar, Zvq, vn, w1) are minified identifiers from the embedded JS bundle and may change across versions.
@Tuxerino420's analysis was performed on Claude Code v2.1.69. The same code structure is present in v2.1.76 based on identical observed behavior.
Call chain (traced from command registration to feature gate):
Command registration: isEnabled: Zvq
Zvq() → vn() → qA("tengu_ccr_bridge", false) → Ar() → !Pv()
The bug is in the Pv() function (determines whether to skip feature-flag evaluation):
function Pv() {
return w1(process.env.CLAUDE_CODE_USE_BEDROCK) ||
w1(process.env.CLAUDE_CODE_USE_VERTEX) ||
w1(process.env.CLAUDE_CODE_USE_FOUNDRY) ||
!!process.env.DISABLE_TELEMETRY || // <-- BUG: uses !! instead of w1()
!!process.env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC // <-- BUG: uses !! instead of w1()
}How it propagates:
Pv()returnstruewhenDISABLE_TELEMETRYis set to any non-empty string (including"0"or"false")Ar()calls!Pv(), which returnsfalseqA()seesfalseand skips all GrowthBook/Statsig feature flag lookups, returning the default value (false) for every gated feature- For
/remote-control: the command registration usesisEnabled: Zvq— whenZvqreturnsfalse, the command is completely hidden from/help, not just disabled - For 1M context: the entitlement check defaults to
false, so Claude Code rejects/model opus[1m]
Features confirmed gated by this path:
- 1M context window entitlement
/remote-controlcommand availability (gated bytengu_ccr_bridgeflag)- Any other feature-gated functionality
Cached feature flags: ~/.claude/.claude.json — @Tuxerino420 confirmed this file correctly contained "tengu_ccr_bridge": true for the account, but the value was never read because qA() bailed out early due to Pv() returning true.
The !! vs w1() sub-bug: DISABLE_TELEMETRY uses !! (JavaScript truthy check) while CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, and CLAUDE_CODE_USE_FOUNDRY all use w1() (proper boolean parser) in the same function. Setting DISABLE_TELEMETRY=0 in settings.json produces process.env.DISABLE_TELEMETRY = "0", and !!"0" is true in JavaScript because "0" is a non-empty string. So explicitly setting telemetry to OFF ("0") has the same effect as ON ("1").
From @Tuxerino420 in #29580:
Minimal fix — use the same w1() boolean parser already used for the other env vars in Pv():
// Before (broken):
!!process.env.DISABLE_TELEMETRY
// After (consistent with Bedrock/Vertex/Foundry checks):
w1(process.env.DISABLE_TELEMETRY)Apply the same fix to CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC:
// Before (broken):
!!process.env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC
// After (consistent):
w1(process.env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC)This would make "0" and "false" behave as expected (falsy), matching the behavior of CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, etc.
Better fix — decouple telemetry preferences from feature entitlements entirely. The Pv() function's purpose is to determine if the client should contact Statsig/GrowthBook, but it conflates "user doesn't want telemetry" with "user is on a third-party provider that can't reach Anthropic's feature-flag servers." These are fundamentally different situations. Telemetry opt-out should disable analytics data collection without affecting feature-gate evaluation for paid entitlements.
Source: All source code analysis, call chain trace, and patch suggestion from @Tuxerino420 in #29580 (Claude Code v2.1.69, Fedora Linux + Windows 11).
Use the same w1() boolean parser already used for Bedrock/Vertex/Foundry env vars:
// Before (broken):
!!process.env.DISABLE_TELEMETRY
// After (consistent):
w1(process.env.DISABLE_TELEMETRY)More fundamentally: telemetry preferences should not gate functional features. These should be independent settings evaluated through separate code paths.
Update: A binary patch is now available in this repository (patch_claude_binary.py) that fixes the feature-gate bypass while keeping DISABLE_TELEMETRY=1 in settings. See the Quick Start at the top of this file.
Without the binary patch: There is no configuration-only workaround. The feature-gate lookup is completely bypassed — the telemetry setting and the entitlement check share the same code path. Every confirmed fix without patching involves removing DISABLE_TELEMETRY from settings. Note: adding CLAUDE_CODE_ENABLE_TELEMETRY=1 does NOT fix it — the DISABLE_TELEMETRY key must be removed entirely.
- The official docs describe
DISABLE_TELEMETRYas opting out of "analytics and usage tracking" — not opting out of paid features - The GA announcement says 1M context is "included with subscription" for Max plans with "no additional configuration"
- The model config docs say "Opus is automatically upgraded to 1M context with no additional configuration" on Max plans
- Trail of Bits recommends disabling telemetry as a security best practice
- Users should not have to choose between privacy and access to paid features
Link: 1M context is now generally available for Opus 4.6 and Sonnet 4.6
Key claims:
- Both Claude Opus 4.6 and Sonnet 4.6 now include the full 1M context window at standard pricing
- No beta header required — requests over 200K tokens work automatically
- Standard pricing across the full window ($5/$25 per million tokens for Opus 4.6, $3/$15 for Sonnet 4.6) — no multiplier
- 1M context is included in Claude Code for Max, Team, and Enterprise users with Opus 4.6
- Up to 600 images/PDF pages per request (up from 100)
- Available on Claude Platform, Microsoft Azure Foundry, and Google Cloud Vertex AI
Link: Model configuration - Claude Code Docs
On Max, Team, and Enterprise plans, Opus is automatically upgraded to 1M context with no additional configuration.
| Plan | Opus 4.6 with 1M context | Sonnet 4.6 with 1M context |
|---|---|---|
| Max, Team, Enterprise | Included with subscription | Requires extra usage |
| Pro | Requires extra usage | Requires extra usage |
| API and pay-as-you-go | Full access | Full access |
- To explicitly disable 1M context: set
CLAUDE_CODE_DISABLE_1M_CONTEXT=1 - Use
[1m]suffix with aliases:/model opus[1m],/model sonnet[1m] - "If you don't see it, try restarting your session"
Link: Data usage - Claude Code Docs
DISABLE_TELEMETRYopts out of Statsig analytics/usage trackingDISABLE_ERROR_REPORTINGopts out of Sentry error loggingCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICis an umbrella that disables all non-essential traffic (also disables auto-updates per Trail of Bits)
Common privacy-focused configuration (recommended by Trail of Bits and privacy guides) that triggers this bug:
{
"env": {
"DISABLE_TELEMETRY": "1",
"DISABLE_ERROR_REPORTING": "1",
"CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1"
}
}Note: DISABLE_NON_ESSENTIAL_MODEL_CALLS does not exist in v2.1.76 (0 occurrences in the binary) — it has no effect and should be removed from configs that reference it.
Of these flags, DISABLE_TELEMETRY is confirmed to trigger the feature-gate bypass. CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY is not in the Pv() function and should be safe. DISABLE_ERROR_REPORTING is not confirmed in Pv() but may be related through an untraced code path.
The Trail of Bits config also recommends the equivalent umbrella setting CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, which is confirmed to trigger the same bug via the Pv() function.
Link: Release v2.1.75
- Opus 4.6 uses a 1M context window by default on Max, Team, and Enterprise plans
- Tool permission denials prompt for a reason when intent is unclear
- Memory files show last-modified timestamps
- Bug fixes: voice mode, header model name display, session crashes, Bash
!mangling
Link: Release v2.1.76
- Added
/effortcommand (low/medium/high/max) - Opus 4.6 defaults to medium effort for Max and Team
- "ultrathink" keyword re-introduced for high effort
- Opus 4 and 4.1 removed — users auto-moved to Opus 4.6
- Default Opus model on Bedrock/Vertex/Foundry changed to Opus 4.6
- Fixed: spurious "Context limit reached" errors on 1M sessions
- Fixed: "adaptive thinking is not supported" errors with non-standard model strings
- Fixed: auto-compaction retrying indefinitely (circuit breaker after 3 attempts)
Link: Release v2.1.77
- Minified function names changed (telemetry_gate:
Zv→Cv, analytics_gate:u1_→o1_, statsig_gate:Ai→hi, extra_usage_check:bf7→Ij7, feedback_gate:L8T→v8T) - This patch script supports v2.1.77 via
KNOWN_VERSIONS["2.1.77"]
- Plan: Claude Max Account (confirmed via
/status) - Claude Code version: 2.1.76 (confirmed latest via
claude --version) - Model: Default Opus 4.6 (confirmed via
/status— "Default Opus 4.6 - Most capable for complex work") - Login method: Claude Max Account (confirmed via
/status) - Platform: macOS (Darwin 25.2.0)
- Shell: zsh
- API provider: First-party Anthropic (not Bedrock, Vertex, or Foundry)
- Setting sources: User settings, Project local settings
~/.claude/settings.json contains:
{
"env": {
"DISABLE_ERROR_REPORTING": "1",
"DISABLE_TELEMETRY": "1"
}
}DISABLE_TELEMETRY is the root cause. DISABLE_ERROR_REPORTING is not in Pv() and does not trigger this bug independently.
No availableModels restrictions, no model overrides, no context-related settings in any settings file (~/.claude/settings.json, ~/.claude/settings.local.json, .claude/settings.local.json).
/contextdisplaysclaude-opus-4-6 . 23k/200k tokens (12%)— capped at 200k/model opus[1m]returns: "Opus 4.6 with 1M context is not available for your account"/remote-controlis unavailable — confirmed same root cause per #29580 and #34083
- Checked Claude Code version — confirmed 2.1.76 (latest), includes 1M support added in v2.1.75
- Switched model to Opus via
/model default— Opus 4.6 selected but/contextstill showed 200k - Attempted
/model opus[1m]— rejected with error above - Checked all context-related environment variables —
CLAUDE_CODE_DISABLE_1M_CONTEXT,ANTHROPIC_DEFAULT_OPUS_MODEL,ANTHROPIC_DEFAULT_SONNET_MODEL,ANTHROPIC_MODEL,CLAUDE_CODE_MAX_CONTEXT,DISABLE_PROMPT_CACHING, allDISABLE_PROMPT_CACHING_*— all unset - Inspected all settings files — no
availableModelsrestrictions, no model overrides in any of the 3 settings files - Verified no third-party provider config — no Bedrock/Vertex/Foundry env vars set
- Searched web and GitHub — found root cause documented across issues #34143, #34083, #29580
- Read official docs — confirmed Max plans should get Opus 1M automatically; docs do not mention
DISABLE_TELEMETRYblocks this - Identified root cause —
DISABLE_TELEMETRYcausesPv()incli.jsto bypass all feature-gate evaluation
| Issue | Title | Date |
|---|---|---|
| #29580 | DISABLE_TELEMETRY=1 breaks remote-control with misleading "not yet enabled" error (includes source code trace) | Feb 28, 2026 |
| #34083 | Max plan: 1M context window shows 200k, Remote Control unavailable | Mar 13, 2026 |
| #34143 | Opus 4.6 shows 200K context instead of 1M on Claude Max plan (v2.1.75) | Mar 13, 2026 |
| #34435 | Opus 4.6 default model alias not using 1M context window (v2.1.76, Max) | Mar 14, 2026 |
| #33119 | Remote Control not enabled on Max plan account | Mar 2026 |
| Issue | Title | Date |
|---|---|---|
| #23432 | /context command reports 200K max for Opus 4.6 instead of 1M | Feb 5, 2026 |
| #23472 | Opus 4.6 with [1m] returns "long context beta not available" on Max subscription | Feb 2026 |
| #23700 | Long context beta unavailable for Max plan with Opus 4.6 1M | Feb 2026 |
| #23714 | Opus 4.6 implies 1M but hard-caps at 200K — session crashes (Max 20x) | Feb 2026 |
| #23879 | Bring 1M context window to Max plan subscribers | Feb 2026 |
| #24208 | Opus 4.6 context display shows 200k instead of 1M | Feb 2026 |
| Issue | Title | Date |
|---|---|---|
| #26428 | Sonnet 1M disappeared after update to v2.1.45 — regression on Max ($200/mo) | Feb 2026 |
| #28723 | Unclear how 1M context billing works on Max subscription | Mar 2026 |
| #28927 | Silent billing change in v2.1.51: 1M moved to extra-usage-only without notice | Mar 2026 |
| #28975 | Opus 1M hits "Rate limit reached" on Max and Team plans | Mar 2026 |
| #29330 | Opus 1M suddenly returns "Rate limit reached" on Max and Team (200K works fine) | Mar 2026 |
| #33154 | Cowork forces [1m] causing instant rate limit errors on Max | Mar 11, 2026 |
| #33584 | Feature request: mid-tier context (400K) at standard Max rates | Mar 12, 2026 |
| Issue | Title | Date |
|---|---|---|
| #19117 | Telemetry Configuration Ambiguity: Confusion between Statsig metrics and OpenTelemetry | 2026 |
| #10494 | DISABLE_TELEMETRY flag ignored — Claude Code connects to Google despite opt-out | 2025 |
| #5508 | OpenTelemetry telemetry cannot be disabled on Windows | 2025 |
| Issue | Title | Date |
|---|---|---|
| #5644 | Feature Request: Enable 1M Context Window for Claude Code | Aug 2025 |
| Issue | Title | Date |
|---|---|---|
| #32673 | Bedrock: 1M context should auto-enable for capable models | Mar 2026 |
From #34143:
- @Hoernchen: First identified the root cause —
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICorDISABLE_TELEMETRY=1blocks 1M context (6 thumbs up). - @davidlandais: Confirmed the fix. "It's a shame you have to disable this option to get access to 1M context. Not very honest."
- @ZenAlexa: Confirmed on Windows 11 + v2.1.76 + Max plan. "Users shouldn't have to opt into telemetry to access a paid feature."
From #34083:
- @lopi-py: Enabling telemetry fixed both 1M context and
/remote-control. - @cwilso03: Confirmed removing
DISABLE_TELEMETRYfrom settings.json immediately restored 1M. Adding it back removed 1M again. Provided the exact block to look for:"env": { "DISABLE_TELEMETRY": "1" }
- @certiv-dwager: Speculates staged rollout — "they want to watch their metrics closely. so rolling out to telemetry enabled users first."
- @inevity: Setting
CLAUDE_CODE_ENABLE_TELEMETRY=1did NOT fix it — theDISABLE_TELEMETRYkey must be removed entirely.
From #29580:
- @Tuxerino420: Full source code trace of
Pv()→qA()→Ar(). DiscoveredDISABLE_TELEMETRY=0also triggers the bug (!!"0"istrue). The/remote-controlcommand was completely hidden from/help, not just failing. - @jschneider: First reported the
/remote-controlvariant. Confirmed onlyDISABLE_TELEMETRYwas needed to trigger —CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICwas NOT set.
From #34143:
- @AspireAI-Developer: On Max plan, v2.1.76, macOS — verified none of the known env vars are set, still capped at 200K. Suggests additional factors beyond telemetry.
- @ManufactoryOfCode: Workaround for non-telemetry cases — switch to Haiku in
/model, then re-open/modeland Opus 4.6 (1M) may appear as a separate option. - @chrisgagne: Used 1M with extra usage disabled, but after several minutes the 1M options disappeared from
/model.
From #34083:
- @stripped-down: Same account, same Max plan, same v2.1.76 — Linux VM gets 1M immediately, macOS still shows 200K (telemetry enabled on both). Suggests platform-gated rollout may also be a factor.
- @Nantris: "It's just random. I use it across several machines with identical settings and some have 1M and some don't."
- @kexgev: Had 1M yesterday, Max plan expired and re-purchased, now shows 200K again.
From #23432:
- @nerdpudding: Got 1M working on Max with extra usage enabled, but performance degraded past 250K tokens — slower responses and more errors past 350K. Noted the "Billed as extra usage" warning when switching to
opus[1m]. - @Notum: Before GA, 1M beta was only for API users with Tier 3+ plans, not Max subscribers — despite Max marketing listing 1M as a feature.
- @felipekj: Max 20x subscriber, extra usage enabled, v2.1.49 — still got "The long context beta is not yet available for this subscription."
- @peixotorms: Had 1M for several days on Max 20x, then it reverted to 200K without any config change.
- @OZmasterAI: Provided a statusline workaround script to recalculate context percentage from actual token counts when the reported window is wrong.
-
Comment on #34083 (oldest post-GA issue, March 13) documenting this case and the root cause
-
Request Anthropic decouple telemetry from feature gates — the fix is straightforward (use
w1()instead of!!inPv(), or better, separate the code paths entirely) -
Do NOT remove
DISABLE_TELEMETRY— telemetry opt-out is a legitimate privacy choice and should not be required for paid features -
Try re-authenticating as a long shot (won't fix the telemetry root cause but rules out stale auth):
claude logout claude login -
Monitor these issues for an official fix:
- 1M context GA announcement (March 13, 2026)
- Model configuration docs
- Data usage / telemetry docs
- Claude Code v2.1.75 release
- Claude Code v2.1.76 release
- What's new in Claude 4.6
- Context windows docs
- Trail of Bits claude-code-config — Security-focused configuration recommendations
- Configuring Claude Code for Privacy — Privacy configuration guide