claude-code - 💡(How to fix) Fix [BUG] Agent-teams teammate panes wedged with "<Box> can't be nested inside <Text>" Ink error on 2.1.119 — not reproducible on 2.1.138 (regression record + fix confirmation) [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#57892Fetched 2026-05-11 03:22:41
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Participants
Timeline (top)
labeled ×6

Error Message

[BUG] Agent-teams teammate panes wedged with "<Box> can't be nested inside <Text>" Ink error on 2.1.119 — not reproducible on 2.1.138 (regression record + fix confirmation) On Claude Code 2.1.119, agent-teams teammate panes spawned via TeamCreate + Agent({team_name}) deterministically crashed their Ink renderer with <Box> can't be nested inside <Text> component (thrown from cli.js:502:249) the first time a permission prompt rendered while the "N MCP server needs auth · /mcp" footer banner was active. The Claude process and tmux pane stayed alive (pgrep found the PID, tmux list-panes reported dead=0, team config still said isActive: true), but the teammate's message-consume loop wedged behind the dead renderer. The team lead saw indefinite silence — no error, no idle notification, no shutdown_response. Manual tmux kill-pane was the only recovery; TeamDelete then failed until the wedged member was manually removed from ~/.claude/teams/<team>/config.json. (a) Teammate renders the permission prompt + footer banner without crashing. (b) Even if a render error occurred, it should propagate to the agent-teams supervisor as an agent_crashed event, not present as indefinite silence with isActive: true.

Error Messages/Logs

ERROR <Box> can't be nested inside <Text> throw Error("<Box> can't be nested inside <Text> component"); 4. Observed on 2.1.119: teammate pane crashes with the Box-in-Text error and freezes; no reply; subsequent SendMessages land in inbox JSON but read stays false forever. Reproduced 4× across two runs with two trigger tools (Bash + Write). 2. Independent of this specific crash, the agent-teams supervisor still has no path from "teammate Ink renderer dies" → "team lead sees agent_crashed event." Even if this exact composition is gone, the next render error in a teammate will present identically (silent wedge, isActive: true forever). Either catch render errors in the teammate process and emit an outbound agent_crashed SendMessage, or have the supervisor detect inbox writes accumulating with no read:true updates.

Root Cause

On 2.1.138, the same trigger condition no longer reproduces (see "Additional Information"). I'm filing this anyway because:

  1. The 2.1.119 crash was severe (silent teammate wedge with no signal path) and worth a searchable record in case of regression.
  2. If the fix was intentional, confirming the responsible change/version helps users who hit this on older binaries triage their workaround.
  3. If the non-repro is accidental (e.g. the banner-rendering component got refactored, but the underlying invalid composition still exists in a less-exercised path), it's worth flagging.

Fix Action

Fix / Workaround

On 2.1.138, the same trigger condition no longer reproduces (see "Additional Information"). I'm filing this anyway because:

  1. The 2.1.119 crash was severe (silent teammate wedge with no signal path) and worth a searchable record in case of regression.
  2. If the fix was intentional, confirming the responsible change/version helps users who hit this on older binaries triage their workaround.
  3. If the non-repro is accidental (e.g. the banner-rendering component got refactored, but the underlying invalid composition still exists in a less-exercised path), it's worth flagging.
MethodResult
SendMessage shutdown_request to wedged teammate❌ written to inbox, never marked read
SendMessage plain ping❌ same
Keyboard input on pane❌ no input box rendered
tmux kill-pane -t %N✅ kills pane + claude process
TeamDelete after kill-pane❌ fails: Cannot cleanup team with 1 active member(s). Workaround: manually remove the wedged member from ~/.claude/teams/<team>/config.json then TeamDelete succeeds.

Workaround for users still on 2.1.119 or earlier

Code Example

ctx: 6 / 1000000 (2%)
        1 MCP server needs auth · /mcp

  ERROR  <Box> can't be nested inside <Text>
        component

 /$bunfs/root/src/entrypoints/cli.js:502:249

---

createInstance(H,_,q,K,O){
  if(K.isInsideText && H==="ink-box")
    throw Error("<Box> can't be nested inside <Text> component");
  let T = H==="ink-text" && K.isInsideText ? "ink-virtual-text" : H;
  let $ = Yq_(T);
  ...
}

---

- createInstance (/$bunfs/root/src/entrypoints/cli.js:502:249)
- PL             (/$bunfs/root/src/entrypoints/cli.js:484:58456)
- LYH            (/$bunfs/root/src/entrypoints/cli.js:484:88642)
- rZH            (/$bunfs/root/src/entrypoints/cli.js:484:87842)
- RD6            (/$bunfs/root/src/entrypoints/cli.js:484:86738)
- iZH            (/$bunfs/root/src/entrypoints/cli.js:484:86558)
- jM_            (/$bunfs/root/src/entrypoints/cli.js:484:83272)
- aH             (/$bunfs/root/src/entrypoints/cli.js:484:6552)
- LH             (/$bunfs/root/src/entrypoints/cli.js:484:5006)
- FH             (/$bunfs/root/src/entrypoints/cli.js:484:5318)

---

cat ~/.claude/mcp-needs-auth-cache.json   # must be non-empty

---

TeamCreate({ team_name: "repro" })
   Agent({
     subagent_type: "general-purpose",
     team_name: "repro",
     name: "worker",
     prompt: "Run `ls /tmp/__nope__$$ 2>&1 || echo NOT_FOUND` via Bash and reply with the output."
   })

---

$ cat ~/.claude/mcp-needs-auth-cache.json
{"claude.ai Gmail":      {"timestamp":1777220169909},
 "claude.ai Google Drive":{"timestamp":1777220169912},
 "claude.ai Google Calendar":{"timestamp":1777220169922}}

---

16:16:50  ex-gamma → gp-delta   [DM] work request
16:16:54  gp-delta → team-lead  [permission_request] for Bash
16:17:03  team-lead → gp-delta  [permission_response] granted
~16:17    CRASH (renderer throws). gp-delta sends nothing further.
16:18:38  team-lead → gp-delta  [ping]              — written, read:false
16:21:40  team-lead → gp-delta  [shutdown_request]  — written, read:false

---

$ pgrep -lf "agent-id gp-delta"
40165  /Users/sauravvarma/.local/share/claude/versions/2.1.119
       --agent-id gp-delta@team-stress-test --agent-name gp-delta ...
$ tmux -L claude-swarm-18922 list-panes -a -F '#{pane_id} pid=#{pane_pid} dead=#{pane_dead}'
%2 pid=39574 dead=0   (gp-delta — wedged, but pane reports alive)
RAW_BUFFERClick to expand / collapse

Bug report — formatted for anthropics/claude-code bug_report.yml

Source: BUG-REPORT.md (preserved). Reshaped after 2026-05-10 reverify on 2.1.138.


Title

[BUG] Agent-teams teammate panes wedged with "<Box> can't be nested inside <Text>" Ink error on 2.1.119 — not reproducible on 2.1.138 (regression record + fix confirmation)

Preflight Checklist

  • Searched existing issues — closest matches are #10313 (closed, different Ink CLI crash), #38941 (closed, Yoga/Ink renderer dump), #48670 (open, MCP needs-auth-cache misbehavior — overlaps with the trigger condition here).
  • Single bug report.
  • Latest version — verified on 2.1.138; original evidence on 2.1.119.

What's Wrong?

On Claude Code 2.1.119, agent-teams teammate panes spawned via TeamCreate + Agent({team_name}) deterministically crashed their Ink renderer with <Box> can't be nested inside <Text> component (thrown from cli.js:502:249) the first time a permission prompt rendered while the "N MCP server needs auth · /mcp" footer banner was active. The Claude process and tmux pane stayed alive (pgrep found the PID, tmux list-panes reported dead=0, team config still said isActive: true), but the teammate's message-consume loop wedged behind the dead renderer. The team lead saw indefinite silence — no error, no idle notification, no shutdown_response. Manual tmux kill-pane was the only recovery; TeamDelete then failed until the wedged member was manually removed from ~/.claude/teams/<team>/config.json.

On 2.1.138, the same trigger condition no longer reproduces (see "Additional Information"). I'm filing this anyway because:

  1. The 2.1.119 crash was severe (silent teammate wedge with no signal path) and worth a searchable record in case of regression.
  2. If the fix was intentional, confirming the responsible change/version helps users who hit this on older binaries triage their workaround.
  3. If the non-repro is accidental (e.g. the banner-rendering component got refactored, but the underlying invalid composition still exists in a less-exercised path), it's worth flagging.

What Should Happen?

(a) Teammate renders the permission prompt + footer banner without crashing. (b) Even if a render error occurred, it should propagate to the agent-teams supervisor as an agent_crashed event, not present as indefinite silence with isActive: true.

Error Messages/Logs

From the 2.1.119 wedged teammate pane:

ctx: 6 / 1000000 (2%)
        1 MCP server needs auth · /mcp

  ERROR  <Box> can't be nested inside <Text>
        component

 /$bunfs/root/src/entrypoints/cli.js:502:249

Throwing site (Ink reconciler createInstance, minified from Bun bundle):

createInstance(H,_,q,K,O){
  if(K.isInsideText && H==="ink-box")
    throw Error("<Box> can't be nested inside <Text> component");
  let T = H==="ink-text" && K.isInsideText ? "ink-virtual-text" : H;
  let $ = Yq_(T);
  ...
}

Call stack tail:

- createInstance (/$bunfs/root/src/entrypoints/cli.js:502:249)
- PL             (/$bunfs/root/src/entrypoints/cli.js:484:58456)
- LYH            (/$bunfs/root/src/entrypoints/cli.js:484:88642)
- rZH            (/$bunfs/root/src/entrypoints/cli.js:484:87842)
- RD6            (/$bunfs/root/src/entrypoints/cli.js:484:86738)
- iZH            (/$bunfs/root/src/entrypoints/cli.js:484:86558)
- jM_            (/$bunfs/root/src/entrypoints/cli.js:484:83272)
- aH             (/$bunfs/root/src/entrypoints/cli.js:484:6552)
- LH             (/$bunfs/root/src/entrypoints/cli.js:484:5006)
- FH             (/$bunfs/root/src/entrypoints/cli.js:484:5318)

Names minified (Bun bundle), but line/col offsets are stable for 2.1.119 and should source-map cleanly.

Steps to Reproduce

(Historical — on 2.1.119. Same steps on 2.1.138 do not reproduce; see "Additional Information".)

  1. Ensure at least one MCP server is in needs-auth state:

    cat ~/.claude/mcp-needs-auth-cache.json   # must be non-empty
  2. From a Claude Code session, create a team and spawn one general-purpose teammate:

    TeamCreate({ team_name: "repro" })
    Agent({
      subagent_type: "general-purpose",
      team_name: "repro",
      name: "worker",
      prompt: "Run `ls /tmp/__nope__$$ 2>&1 || echo NOT_FOUND` via Bash and reply with the output."
    })
  3. Wait for the teammate to send a permission_request, then grant it.

  4. Observed on 2.1.119: teammate pane crashes with the Box-in-Text error and freezes; no reply; subsequent SendMessages land in inbox JSON but read stays false forever. Reproduced 4× across two runs with two trigger tools (Bash + Write).

Claude Model

Opus (claude-opus-4-7). Healthy comparison teammate in the same 2.1.119 session used Haiku/Explore and never hit a permission prompt — model was not the variable; the permission-prompt + auth-banner composition was.

Is this a regression?

I don't know. The behavior was new-observation on 2.1.119; not bisected against older versions. (For 2.1.138 the bug appears resolved.)

Last Working Version

N/A — not bisected.

Claude Code Version

Evidence: 2.1.119. Reverify: 2.1.138 (cannot reproduce — see below).

Platform

Anthropic API.

Operating System

macOS (Darwin 25.3.0 / macOS 26.3.1 on the original 2.1.119 host; Darwin 25.4.0 / macOS 26.3.1 on the 2.1.138 reverify host).

Terminal/Shell

Original (2.1.119): iTerm2, agent-teams backend = tmux (socket claude-swarm-18922), teammateMode: "tmux".

Reverify (2.1.138): tested both iTerm2 host (iterm2 backend) and Ghostty host (tmux backend) — neither reproduces.

Additional Information

Reverify on 2.1.138 (2026-05-10)

Same trigger condition (10 MCP servers in ~/.claude/mcp-needs-auth-cache.json, including the same claude.ai connectors that triggered the original crash), same spawn pattern (TeamCreate + general-purpose Agent with team_name), same minimal prompts (single Bash perm prompt; multi-stage Bash + Write + Read perm prompts). Three runs:

#Host terminalBackend (per team config)StagesResult
1iTerm2iterm2Bash perm promptWorker replied cleanly in ~36s
2iTerm2iterm2Bash + Write + Read perm promptsAll stages clean in ~24s
3GhosttytmuxBash + Write + Read perm promptsAll stages clean in ~20s

Run 3 is the closest match to the 2.1.119 conditions (tmux backend, same trigger). It does not reproduce.

2.1.119 evidence (preserved)

MCP needs-auth state at teammate spawn (original):

$ cat ~/.claude/mcp-needs-auth-cache.json
{"claude.ai Gmail":      {"timestamp":1777220169909},
 "claude.ai Google Drive":{"timestamp":1777220169912},
 "claude.ai Google Calendar":{"timestamp":1777220169922}}

All three timestamps = 2026-04-26 16:16:09 UTC, ~4 seconds before the wedged teammate spawned.

Round-by-round (2.1.119):

RoundSpawn timeMCP needs-authOutcome
R1 (gp-alpha, gp-beta)16:11–16:13emptyAll 5 stages passed
R2 (ex-gamma, gp-delta)16:16:13+3 serversgp-delta crashed on first permission-prompted Bash
R2 retry16:18+3 serversgp-delta crashed on first permission-prompted Write
Stage Claterre-populated (had "disabled" via /mcp but it re-populated)crashed identically

Timeline from inbox JSON (R2):

16:16:50  ex-gamma → gp-delta   [DM] work request
16:16:54  gp-delta → team-lead  [permission_request] for Bash
16:17:03  team-lead → gp-delta  [permission_response] granted
~16:17    CRASH (renderer throws). gp-delta sends nothing further.
16:18:38  team-lead → gp-delta  [ping]              — written, read:false
16:21:40  team-lead → gp-delta  [shutdown_request]  — written, read:false

Process state during the wedge:

$ pgrep -lf "agent-id gp-delta"
40165  /Users/sauravvarma/.local/share/claude/versions/2.1.119
       --agent-id gp-delta@team-stress-test --agent-name gp-delta ...
$ tmux -L claude-swarm-18922 list-panes -a -F '#{pane_id} pid=#{pane_pid} dead=#{pane_dead}'
%2 pid=39574 dead=0   (gp-delta — wedged, but pane reports alive)

team-config.json continued to list gp-delta as isActive: true indefinitely.

Recovery on 2.1.119 (verified)

MethodResult
SendMessage shutdown_request to wedged teammate❌ written to inbox, never marked read
SendMessage plain ping❌ same
Keyboard input on pane❌ no input box rendered
tmux kill-pane -t %N✅ kills pane + claude process
TeamDelete after kill-pane❌ fails: Cannot cleanup team with 1 active member(s). Workaround: manually remove the wedged member from ~/.claude/teams/<team>/config.json then TeamDelete succeeds.

Suggested investigation areas

  1. Identify and confirm the change between 2.1.119 and 2.1.138 that resolved this — likely a fix in the component rendering the "N MCP server needs auth · /mcp" footer banner (composed <Box> inside <Text> only when paired with a permission-prompt panel).
  2. Independent of this specific crash, the agent-teams supervisor still has no path from "teammate Ink renderer dies" → "team lead sees agent_crashed event." Even if this exact composition is gone, the next render error in a teammate will present identically (silent wedge, isActive: true forever). Either catch render errors in the teammate process and emit an outbound agent_crashed SendMessage, or have the supervisor detect inbox writes accumulating with no read:true updates.
  3. TeamDelete should accept a force flag, or auto-clean when a member is unreachable.
  4. Related: mcp-needs-auth-cache.json repopulating within minutes even after /mcp disable (and disabledMcpServers not taking effect mid-session) — overlap with #48670.

Workaround for users still on 2.1.119 or earlier

Before any agent-teams session, ensure ~/.claude/mcp-needs-auth-cache.json is empty. If non-empty:

  • Complete /mcp auth for each listed server and then restart Claude Code (the disable does not take effect inside a running session), or
  • Add the listed server names to projects[<your-cwd>].disabledMcpServers in ~/.claude.json and restart.

Do not just delete the cache file — it re-populates within minutes.

Cross-references

  • #10313 (closed) — earlier generic Ink CLI crash
  • #38941 (closed) — Yoga/Ink renderer source dump on crash
  • #48670 (open) — MCP needs-auth-cache blocks reconnection even after re-auth (same underlying cache-staleness that produces the persistent banner observed here)

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Agent-teams teammate panes wedged with "<Box> can't be nested inside <Text>" Ink error on 2.1.119 — not reproducible on 2.1.138 (regression record + fix confirmation) [1 participants]