[BUG] Agent Teams teammates lose [1m] context window suffix — root cause: tmux spawn hardcodes model without variant

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27261
2. https://github.com/anthropics/claude-code/issues/26109
3. https://github.com/anthropics/claude-code/issues/23561

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

@Danie1Ka0 @lukaemon @mcande21 @mriffault

Feel free to use this patch (CC created) until the official fix is available. I have tested it on MacOS with CC version 2.1.76. it will make the teammates match the lead instead of using a hardcoded default.
https://gist.github.com/keyur2maru/0d2e4e728d7537aa7c36cbc936b2b6b4

thanks for sharing

@Danie1Ka0 @lukaemon @mcande21 @mriffault Feel free to use this patch (CC created) until the official fix is available. I have tested it on MacOS with CC version 2.1.76. it will make the teammates match the lead instead of using a hardcoded default. https://gist.github.com/keyur2maru/0d2e4e728d7537aa7c36cbc936b2b6b4

Still present on v2.1.77 (Max plan)

Environment:

• Claude Code v2.1.77
• Max plan (which should auto-upgrade Opus to 1M server-side per v2.1.75 changelog)
• ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-6[1m]
• CLAUDE_CODE_SUBAGENT_MODEL=claude-opus-4-6[1m]

Observed: Teammates spawned via Agent tool with team_name parameter still receive --model claude-opus-4-6 (200K) instead of claude-opus-4-6[1m]. Confirmed by checking the spawned teammate's session — it does not show 1M context.

Interestingly, subagents (Task/Agent tool without team_name, in-process) correctly inherit [1m] from the parent session. Only out-of-process teammates lose it.

Workaround: CLAUDE_CODE_TEAMMATE_COMMAND wrapper

Created a wrapper script that intercepts the --model argument and appends [1m]:

#!/bin/bash
# ~/.claude/teammate-wrapper.sh
# Workaround for #34421: teammates lose [1m] suffix
args=()
for arg in "$@"; do
  if [[ "$arg" == "claude-opus-4-6" ]]; then
    args+=("claude-opus-4-6[1m]")
  else
    args+=("$arg")
  fi
done
exec claude "${args[@]}"

Then in ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_TEAMMATE_COMMAND": "/home/user/.claude/teammate-wrapper.sh"
  }
}

This works — next spawned teammates correctly get 1M context. Sharing in case it helps others until the root cause is fixed.

This is related to cozempic's 1M context detection — we had to implement the same workaround. [1m] gets treated as a variant suffix, not part of the model ID, and gets dropped in various string-manipulation paths.

If you're using cozempic with affected sessions, the guard will still correctly detect the actual context window in use — it reads the model field from the JSONL usage data directly, so it sees whatever Claude Code actually ran with. The teammate side is a separate bug in how CC constructs the tmux spawn command.

Noting here in case it's useful for the root cause investigation.

Still experiencing this — teammates get 200k context while the leader runs opus[1m]. The tmux spawn path still hardcodes the model without the variant suffix.

🤖 Generated with Claude Code

Still broken on v2.1.87 (latest). Filed #40929 with detailed testing of all known workarounds — none work on the current version. The binary patch from the gist no longer applies due to minified name changes.

Standalone subagents inherit 1M correctly. Only teammates (tmux spawn path) are affected. The --model flag in the subprocess command always strips [1m].

I found a workaround for the issue. Setting "teammateDefaultModel": null in the Claude Code settings(~/.claude.json) makes it use the same model as the orchestrator. Also, the orchestrator that spawns the teammate should not select a model explicitly when spawning

Workaround(Edited)

• Set /model opus[1m] (not default opus[1m]) // This is important
• Set "teammateDefaultModel": null in ~/.claude.json
• Say to the orchestrator "Don't override a model of teammate"

<img width="1919" height="603" alt="Image" src="https://github.com/user-attachments/assets/9a10502a-7a0e-4b3b-b1c4-0aee508bc084" />

Confirmed workaround on v2.1.92 (latest) — @Reasonably's approach works

Tested on Claude Code v2.1.92, Claude Max, macOS, iTerm2 with \tmux -CC\:

Steps

1. Add \"teammateDefaultModel": null\ to \~/.claude.json\
2. In the lead session, run \/model opus[1m]\ (must explicitly select this — NOT "Default (recommended)")
3. Spawn teammates without passing the \model\ parameter

Result

Teammate banner shows "Opus 4.6 (1M context)" and \/context\ confirms \1000k\ window. Without the workaround, same setup shows "Opus 4.6" with \200k\ window.

Additional finding: tmux-specific bug

Also confirmed through testing across three terminal configurations that this bug is specific to the tmux split-pane backend:

| Terminal | tmux? | Teammate context |
|----------|-------|-----------------|
| iTerm2 + \tmux -CC\ | Yes | 200K (without workaround) |
| iTerm2 (no tmux) | No | 1M (no workaround needed) |
| Ghostty | No | 1M (no workaround needed) |

The in-process backend correctly preserves \[1m]\. Only the tmux pane spawn path strips it. The workaround above fixes it for tmux users.

Why it works

"Default (recommended)" resolves the model ID to \claude-opus-4-6\ internally (without \[1m]\). Explicitly selecting \/model opus[1m]\ keeps the \[1m]\ suffix in the resolved ID. Setting \teammateDefaultModel: null\ tells the teammate spawn path to inherit the lead's resolved model rather than computing its own default — so the \[1m]\ propagates through.

<img width="810" height="222" alt="Image" src="https://github.com/user-attachments/assets/afaa60a6-d919-4f3a-a06a-9b7700b83ffc" />

able to set teammate model in /config. v2.1.104

able to set teammate model in /config. v2.1.104

Not working at all. Still start teammate with Sonnet 4.6.

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.