[BUG] [1M] Opus 4.6 1M context unavailable on Max 5x — works on another machine with same account

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/34333
2. https://github.com/anthropics/claude-code/issues/34585
3. https://github.com/anthropics/claude-code/issues/34795

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not closing as duplicate — this issue adds the specific detail that the feature works on a different machine with the same Max 5x account, pointing to a client-side or platform-detection issue rather than a pure account entitlement problem. The WSL2 platform detail is unique to this report. See also #34795 for the closest match.

Same here

I'm on Windows 11, native binary, and statusline and context 1m is seen, yet every session collapses at 197k+ and says context limit reached.

Ok, I managed to find the root of the problem and fix it on my machine, perhaps it can be helpful for others who used the limit override.

Removing CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE on Windows

If you previously set CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE and want to remove it (e.g., to use the full 1M context window on Opus 4.6), you need to clean it from all of these locations. Missing even one will keep the old limit active.

Step 1: Remove from Windows Registry

Open PowerShell and run:

# Check current value
[Environment]::GetEnvironmentVariable('CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE', 'User')

# Remove it
[Environment]::SetEnvironmentVariable('CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE', [NullString]::Value, 'User')

Step 2: Remove from VS Code/Cursor settings

File: %APPDATA%\Code\User\settings.json, %APPDATA%\Cursor\User\settings.json`

Remove or empty these two settings:

// Remove the env var from terminal environment
"terminal.integrated.env.windows": {
    "CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE": "197000"  // ← delete this line
},

// Remove from Claude Code extension environment
"claudeCode.environmentVariables": [
    {
        "name": "CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE",  // ← delete this entry
        "value": "197000"
    }
],

Step 3: Clear cached terminal state databases

Close VS Code and Cursor completely, then delete state.vscdb files that cached the old env var. From Git Bash:

# Find and delete VS Code workspace state DBs that contain the cached value
for f in ~/AppData/Roaming/Code/User/workspaceStorage/*/state.vscdb \
         ~/AppData/Roaming/Code/User/workspaceStorage/*/state.vscdb.backup; do
    grep -ql "BLOCKING" "$f" 2>/dev/null && rm -v "$f"
done

# Same for Cursor
for f in ~/AppData/Roaming/Cursor/User/workspaceStorage/*/state.vscdb \
         ~/AppData/Roaming/Cursor/User/workspaceStorage/*/state.vscdb.backup; do
    grep -ql "BLOCKING" "$f" 2>/dev/null && rm -v "$f"
done

These are SQLite databases where VS Code/Cursor persist terminal environments. They'll be recreated automatically on next launch — no real work is lost.

Step 4: Restart Windows (log out / log in)

A full Windows restart (or log out + log in) is required because running processes cache environment variables from when they were spawned. Restarting Explorer alone is not sufficient — VS Code and Cursor may have been launched from cached process trees that still carry the old value.

Verification

After restarting, open VS Code and run in the terminal:

echo "${CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE:-NOT SET}"

Should print NOT SET. The full 1M context window is now active for Opus 4.6.

I run Claude Code on the same WSL2 kernel (6.6.87.2-microsoft-standard-WSL2) daily. A few diagnostic steps specific to the WSL2 + Windows dual-environment:

1. Check for leaked Windows env vars

WSL2 can inherit environment variables from the Windows side via WSLENV. If CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE was ever set on the Windows host (as @i-dedova discovered), it may be leaking into WSL2:

# Check if the var exists in WSL2
echo $CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE

# Check if WSLENV is passing it
echo $WSLENV

# Also check Windows-side env vars visible to WSL2
powershell.exe -Command "[Environment]::GetEnvironmentVariable(\"CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE\", \"User\")"
powershell.exe -Command "[Environment]::GetEnvironmentVariable(\"CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE\", \"Machine\")"

If any of these return a value, remove it on the Windows side and restart WSL2 (wsl --shutdown from PowerShell, then relaunch).

2. Platform identification mismatch

Claude Code on WSL2 reports platform: linux to Anthropic's servers (verified: node -e "console.log(process.platform)" → linux), while the native Windows install reports win32. If 1M feature-gating has any platform-specific logic server-side, this could explain why the same account works natively but not under WSL2.

You can check what platform string your client sends by looking at the debug logs after running claude --debug:

grep -i "platform" ~/.claude/debug/*.txt 2>/dev/null | head -5

3. Credential file comparison

Compare the credential structure between the working Windows machine and WSL2:

# On WSL2
cat ~/.claude/.credentials.json | python3 -m json.tool

# On the working Windows machine (from PowerShell)
Get-Content "$env:USERPROFILE\.claude\.credentials.json" | ConvertFrom-Json | ConvertTo-Json

Look for any differences in rateLimitTier, planType, or feature flag fields. The WSL2 client might be authenticating with a different OAuth flow that returns a different entitlement set.

4. npm install path isolation

Ensure the WSL2 npm global install is completely separate from the Windows one:

which claude        # should be /home/<user>/.npm-global/bin/claude or similar
npm list -g @anthropic-ai/claude-code

If it resolves to /mnt/c/..., you're accidentally running the Windows binary through WSL2 interop, which can cause authentication confusion.

Found a workaround via #34435:

Set the environment variable:

ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-6[1m]

Or add it to ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-6[1m]"
  }
}

<img width="677" height="366" alt="Image" src="https://github.com/user-attachments/assets/202178e9-3949-4421-85fc-4e3892ddf0e1" />

Both approaches work. The original question remains — shouldn't this be the default for Max subscribers?

Likely the same underlying issue as #35269 — since ~2026-03-16 22:00 UTC, Max plan OAuth tokens return 400 {"type":"invalid_request_error","message":"Error"} for claude-opus-4-6 and claude-sonnet-4-6 specifically. Claude Code silently falls back to Haiku. The 1M context unavailability may be a symptom of Opus being blocked entirely rather than a separate context window issue.

I just wanted to say that I have the Max 20x plan and getting the same issue. On one windows machine showed up fine, on another will not show the 1 million context version.

After updating to the latest version 2.1.78, a 1MB context view is available.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.