Claude context window shows 1M when CLAUDE_CODE_DISABLE_1M_CONTEXT is set, so idle compaction never runs and resumed threads hit blocking_limit #31441

What happened

A long Claude thread (claude-opus-5-5) sat idle overnight. The next message failed immediately with "Claude stopped: the prompt exceeds the model's context window. Run /compact or start a new thread." T3 did not compact the thread before sending, and the context meter showed it far from full.

Diagnosis

The user's ~/.claude/settings.json sets env.CLAUDE_CODE_DISABLE_1M_CONTEXT=1, so Claude Code runs Opus with a 200k window. Its result.modelUsage reports contextWindow: 200000.

T3 still treats the window as 1M:

• claudeContextWindow (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts:4861-4864) uses the catalog value (1,000,000 for opus) before reportedContextWindows, so the reported 200k is only a fallback. The thread's provider turns store maxTokens: 1000000, and the meter showed ~16% at ~160k.
• Idle compaction and the "Compact and send" chip need at least COMPACTION_SUGGESTION_MIN_TOKENS = 200_000 (packages/shared/src/claudeCompaction.ts:46). In a 200k window, Claude Code refuses well before that, so T3 never compacts.

What tipped it over: T3 closed the idle query after 30 min. On resume, Claude Code re-attached the project's AGENTS.md (83 KB, ~20k tokens, edited since the last load) as a session_start instructions attachment. The last turn was at ~159.6k. With the attachment added, the CLI hit its local blocking limit and returned a synthetic "Prompt is too long" (terminal_reason: blocking_limit) without calling the API or auto-compacting.

Both code paths are unchanged on main. Suggested direction: prefer the window Claude reports (or honor CLAUDE_CODE_DISABLE_1M_CONTEXT) over the catalog, and scale the compaction minimum to the effective window.

Steps to reproduce

1. In ~/.claude/settings.json, set "env": { "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1" }.
2. In T3, use a Claude Opus thread until its context is ~160k (Claude auto-compacts around 167k).
3. Note that the context meter uses a 1M maximum.
4. Leave the thread idle past the prompt-cache TTL (1h) so T3 closes the query. No Compact chip appears.
5. Send a message. With a large AGENTS.md/CLAUDE.md that changed since the session last loaded it, the resumed turn fails at once with blocking_limit.

Version

0.1.8-nightly.20261105.4218 (desktop app, local server)

Environment

macOS 27.0.0 arm64, Node v24.22.1, Claude Code 2.1.318, model claude-opus-5-5 (effort high)

Evidence

Last good turn (provider turn tokenUsage):

{"usedTokens":159649,"maxTokens":1000000,"inputTokens":159405,...}

Idle close, then resume ~12h later (provider event log):

23:49:30Z outgoing query.close
11:36:30Z outgoing query.open {"model":"claude-opus-5-5","resume":"<session>",...}

Claude transcript on resume: `attachment {"type":"instructions","reason":"session_start","changed":true,"files":[AGENTS.md, 82924 chars]}`, then:

assistant model="<synthetic>" text="Prompt is too long"
result is_error=true terminal_reason="blocking_limit"
  modelUsage.claude-opus-5-5.contextWindow=200000

Earlier auto-compactions on the same thread: pre_tokens 167195 / 168193 / 169547 / 172267, all success.

Related issues

• Claude "Prompt is too long" (terminal_reason blocking_limit) is shown as "Usage limit reached" #19832 (closed): the same blocking_limit result was mislabeled as a usage limit. That is fixed; the message is now correct. This issue is about why T3 reached that state.
• [Bug]: Sending /clear on a stale Claude thread compacts the old context first, then clears #31092: compact-before-send on stale Claude threads, but about /clear, not window detection.

Fix applied or workaround

Nothing was changed on the machine. Workarounds: run /compact in the thread, then resend; or remove CLAUDE_CODE_DISABLE_1M_CONTEXT if the plan supports 1M context.

Filed by

Claude Code (claude-opus-5-5) via T3 Code triage