[Bug]: Claude 200k context window selection is a no-op; sessions always run at 1M #8405

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Pick Claude Opus 5 (or Fable 5 / Sonnet 5) in the composer.
2. Set Context Window → 200k.
3. Send a turn.
4. Inspect what the provider actually ran — e.g. read modelUsage[<model>].contextWindow off the SDK result, or look at the maxTokens values T3 persists in orchestration_events.

The session runs at 1,000,000 tokens, not 200,000. The 200k selection has no effect on the request.

Expected behavior

Selecting 200k should make Claude Code run the 200k context window.

Actual behavior

The 200k selection is a no-op. resolveClaudeApiModelId (apps/server/src/provider/Layers/ClaudeProvider.ts:458) encodes the choice purely in the model slug:

export function resolveClaudeApiModelId(modelSelection: ModelSelection): string {
  switch (resolveClaudeContextWindow(modelSelection)) {
    case "1m":  return `${modelSelection.model}[1m]`;
    default:    return modelSelection.model;   // assumed to mean 200k
  }
}

The bare slug does not mean 200k. Claude Code auto-enables the 1M window for these models unless the process env sets CLAUDE_CODE_DISABLE_1M_CONTEXT=1. So T3 spawns --model claude-opus-5, and the session runs at 1M anyway.

Three runs, same SDK (@anthropic-ai/claude-agent-sdk 0.3.170) and same binary (Claude Code 2.1.247), reading modelUsage[].contextWindow off the result message:

Same via the bare CLI, no SDK involved:

$ claude --model claude-opus-5 --output-format json -p "hi" | jq '.modelUsage | map_values(.contextWindow)'
{ "claude-opus-5": 1000000 }

Confirmed for all three models that expose the Context Window trait: claude-opus-5, claude-fable-5, claude-sonnet-5 all report 1,000,000 when passed as a bare slug.

Not environment-specific — reproduces identically on a local server and on a desktop-managed SSH remote. In both cases the selection reaches the server intact (projection_threads.model_selection_json contains {"id":"contextWindow","value":"200k"}) and the spawned process has a clean env and --model claude-opus-5.

Impact

Major degradation or frequent failure

Version or commit

0.0.36-nightly.20260827.1205

Environment

macOS 26.6.2 + Linux SSH remote; Claude Code 2.1.247; @anthropic-ai/claude-agent-sdk 0.3.170; Claude Max OAuth

Logs or stack traces

# T3 persists Claude Code's own report of the live window.
# A thread whose stored selection is 200k:
#   projection_threads.model_selection_json
#     {"instanceId":"claudeAgent","model":"claude-opus-5",
#      "options":[{"id":"effort","value":"xhigh"},{"id":"contextWindow","value":"200k"}]}
#   orchestration_events payloads for that thread:
#     {"maxTokens": 1000000} x60

Workaround

None from the UI. Selecting 1M vs 200k makes no difference to the request; both run at 1M.

Suggested fix

Set the env var alongside the slug, at the single queryOptions site in apps/server/src/provider/Layers/ClaudeAdapter.ts:4331:

env: {
  ...claudeEnvironment,
  ...(resolveClaudeContextWindow(modelSelection) === "200k"
    ? { CLAUDE_CODE_DISABLE_1M_CONTEXT: "1" }
    : {}),
},

One caveat for whoever picks this up: env is only read at spawn, so the query.setModel() path in sendTurn (ClaudeAdapter.ts:4531) can't flip the window on a live thread — switching 200k↔1M mid-thread would need a session restart to take effect.

Related

• [Bug]: Context Window meter doesn't update with selected context window on Claude sessions #5286 — same root cause, but filed as a cosmetic meter bug. It's the reverse: the meter is the accurate part. selectedClaudeContextWindow seeds it at 200k, then Claude Code's honest report of 1,000,000 overwrites it at ClaudeAdapter.ts:2153.
• [Bug]: Claude is always with 1m context even though 200k context is selected. #2733 — same report, closed as a duplicate of [Bug]: Context limit is set to 200k but the context goes up to 1M #2394. Its one comment already named CLAUDE_CODE_DISABLE_1M_CONTEXT, but the linked PR's fork was deleted.
• [Bug]: Context limit is set to 200k but the context goes up to 1M #2394 — closed in a maintenance sweep with "a new report would need provider request diagnostics". This report provides them.