Agent Teams: subagent permission request crashes the Bun process (2.1.111)

Summary

With the experimental Agent Teams feature enabled (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1), when a parent agent spawns a subagent and that subagent requests tool permission, the approval prompt never renders and the parent Bun process exits. Confirmed regression in 2.1.111 — rolling the symlink back to 2.1.110 makes the same workflow work cleanly.

Environment

• Claude Code: 2.1.111 (installed as native binary, Linux x86_64, Bun-compiled)
• Confirmed not present on 2.1.110 (same machine, same config, symlink flipped — subagent permission prompts render normally)
• OS: Linux 6.17 (Ubuntu-family)
• Models tested: claude-opus-4-6, claude-opus-4-7 — same behavior on both, so the bug is independent of the model.
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is set in user settings.json env. Our subagents are spawned via the experimental Agent Teams feature, so this code path may be the only one exercising whatever shape-mismatch is tripping the explainer.

Reproduction

1. In a parent Claude Code session, spawn a subagent via the Agent tool (we use a team of named subagents; the stock Task tool should reproduce the same way).
2. The subagent issues a tool call (e.g., Bash) that would normally trigger a permission prompt in the parent.
3. Expected: parent UI shows the permission prompt for the operator to approve/deny.
4. Actual: no prompt ever appears; the parent process crashes with the stack trace below.

Stack trace

 - <anonymous> (/$bunfs/root/src/entrypoints/cli.js:8233:15642)
 - $2 (/$bunfs/root/src/entrypoints/cli.js:477:63169)
 - aLH (/$bunfs/root/src/entrypoints/cli.js:477:76220)
 - rV (/$bunfs/root/src/entrypoints/cli.js:477:76101)
 - aLH (/$bunfs/root/src/entrypoints/cli.js:477:76199)
 - rV (/$bunfs/root/src/entrypoints/cli.js:477:76101)
 - aLH (/$bunfs/root/src/entrypoints/cli.js:477:76199)
 - rV (/$bunfs/root/src/entrypoints/cli.js:477:76101)
 - aLH (/$bunfs/root/src/entrypoints/cli.js:477:76199)
 - rV (/$bunfs/root/src/entrypoints/cli.js:477:76101)

The repeating aLH ↔ rV pair at stable offsets looks like a React reconciler recursing to max depth (likely a setState-during-render style loop, triggered by a thrown error in a child component).

Suspected cause

Poking at the bundled cli.js, the frame at 8233:15642 is near the new "permission explainer" feature. Relevant code:

function gM6() { return O$().permissionExplainerEnabled !== false }

async function rQ7({ toolName, toolInput, toolDescription, messages, signal }) {
  if (!gM6()) return null;
  // ...
  const contextText = messages?.length ? Kx1(messages) : "";
  // ...
}

function Kx1(H, $ = 1000) {
  let q = H.filter(A => A.type === "assistant").slice(-3);
  let K = [], _ = 0;
  for (let A of q.reverse()) {
    let f = A.message.content
      .filter(z => z.type === "text")
      .map(z => ("text" in z) ? z.text : "")
      .join(" ");
    // ...
  }
}

Kx1 assumes A.message.content is an array of content blocks. If a subagent's transcript contains a message where content is a string (or any non-array shape), .filter throws. The permission-prompt render path appears to not catch this, so the component throws during render and the reconciler recurses until the process dies.

This is a guess — we haven't run under a debugger. But it matches the symptoms (crash happens exactly when a subagent-originated prompt would render, never on parent-originated prompts) and the new-in-2.1.111 aspect.

Workarounds

• Roll back to 2.1.110 — confirmed working. Flip the launcher symlink (ln -sfn .../versions/2.1.110 ~/.local/bin/claude) and relaunch.
• Setting permissionExplainerEnabled: false in ~/.claude.json should bypass rQ7 entirely (not tested — rollback was enough for us).

What would help

• Confirmation of whether the permission explainer changed in 2.1.111.
• A guard in Kx1 for non-array message.content (or whatever the actual upstream cause turns out to be).
• An error boundary around the permission-prompt render so a thrown explainer doesn't take down the whole process.

Happy to run any additional diagnostics if it would help.