Subagent SendMessage delivery failures: Ink crash and silent tool-call drop in tmux teammate panes

Subagent SendMessage delivery failures: Ink crash and silent tool-call drop in tmux teammate panes

Repository: anthropics/claude-code
Claude Code version: 2.1.119
Subagent model: sonnet (Sonnet 4.6, per Claude Code docs)
Orchestrator model: opus 4.7 (1M context)
Platform: macOS 26.3.1 (Darwin 25.3.0, arm64), tmux 3.6a, TERM=tmux-256color, COLORTERM=truecolor

Summary

In a multi-agent workflow using TeamCreate + Agent(team_name=...) to spawn Sonnet-4.6 codex-reviewer subagents in tmux panes, three consecutive review tasks in the same ~90-minute session failed to deliver their results back to the orchestrator via SendMessage. The failures had different surface symptoms but the same outcome: review file written to disk by an external script, but no SendMessage tool call ever reached the team channel.

All three incidents required manual recovery (orchestrator reading review_N.md from disk).

Failure mode #1 — Ink/React TUI crash in subagent pane

Pane: %101 (codex-reviewer subagent, Sonnet 4.6, tmux)
State at time of crash: had completed commit_review.sh (review_1.md on disk via codex exec --json -o), was about to call SendMessage

Visible stack trace (reconstructed from screenshot before pane was killed):

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 / LH / FH    (additional frames truncated)

createInstance + deeply-nested minified-letter call chain is consistent with Ink/React rendering, not codex CLI execution (the codex side runs non-interactively via codex exec --json -o <file> and would not trigger Ink). The pane became unresponsive; killed via tmux kill-pane -t %101.

Failure mode #2 — Silent tool-call drop (no crash, model emits review as plain text)

Pane: %103 (codex-reviewer-iter2 subagent, Sonnet 4.6, tmux)
State at time of failure: had completed commit_review.sh, model decided to call SendMessage

Pane scrollback excerpt (verbatim, captured live):

⏺ I'll now send the results back to the team-lead via SendMessage.

⏺ Bash(echo "Preparing to invoke SendMessage")
  ⎿  Preparing to invoke SendMessage

⏺ Based on the completed review, I need to use the SendMessage tool to
  deliver the results to team-lead@rtd-memory-slice-5.

  Run ID: 75446_20260425_183538_75449
  Iteration: 2
  Exit status: 0
  Review file: ...review_2.md

  Full raw review_2.md contents:
  ---
  Previous Findings Status
  1. Malformed FTS query escaping...
  [full review pasted as assistant text]
  ...
  Top Recommendations
  1. Correct the schema-validation error-layer docs...

✻ Brewed for 3m 53s

The model emitted the review as plain assistant text, then went idle. No SendMessage tool call appears in the scrollback at all. The model substituted a no-op Bash("echo Preparing to invoke SendMessage") placeholder for the actual tool invocation.

This is reproducible: the dispatch prompt explicitly said _"Use the SendMessage tool to notify team-lead@rtd-memory-slice-5..."_ and listed the recipient name verbatim. The model still never invoked the tool.

Failure mode #3 — Second silent tool-call drop, same pattern as #2

Pane: %104 (codex-reviewer-iter3 subagent, Sonnet 4.6, tmux)
State at time of failure: had completed commit_review.sh (review_3.md on disk), task complete

The dispatch prompt for this third reviewer included an explicit warning paragraph naming both prior failures and forbidding the no-op Bash("echo") substitution that mode #2 used. Quote from the dispatch prompt:

CRITICAL — read this carefully. The two prior codex-reviewer teammates on this team failed to deliver their reviews: - Iter-1 reviewer crashed before SendMessage fired (Ink TUI failure) - Iter-2 reviewer ran a no-op Bash("echo Preparing to invoke SendMessage") placeholder, then output the review as plain assistant text... Do not repeat that mistake. SendMessage is a TOOL CALL, not narration. Calling Bash with echo does NOT count. Writing the review as plain text in your assistant response does NOT count. Saying "I will call SendMessage" does NOT count.

The model still failed to invoke SendMessage. Pane went idle, review_3.md was on disk, no tool call ever dispatched.

This eliminates "the model didn't understand the requirement" as a possible cause. Prompt-level scaffolding does not reliably get Sonnet 4.6 subagents to invoke SendMessage after a long-running task.

Why this matters

SendMessage is the only delivery channel from a teammate back to the orchestrator in tmux-backed teams — the orchestrator does not read teammate stdout. When the tool call drops silently:

• The orchestrator has no signal that work is complete
• Plain-text output in the pane is invisible to the orchestrator
• The teammate goes idle and looks "available," not "failed"
• Manual recovery (operator inspects review_N.md on disk) is the only fallback

Documented in our project CLAUDE.md:

Caught 2026-04-19 when a codex-reviewer teammate completed a commit review, wrote findings to the session log as plain text, and went idle — the orchestrator had to read review_1.md from disk because no SendMessage was ever invoked.

The 2026-04-25 incident in this report is the third occurrence we've logged across rtd-memory and rtd-fde — pattern is recurring.

Reproduction

We don't have a deterministic repro for either failure mode; both happened mid-session. Conditions present in both incidents:

1. Subagent spawned via Agent tool with team_name parameter (Claude Code formal team)
2. Backend: tmux (each teammate gets its own pane)
3. Subagent model: sonnet (Sonnet 4.6)
4. Subagent task: run a long-running shell command (commit_review.sh, ~3-5 min, runs codex exec internally), read the resulting markdown file (~3-5 KB), SendMessage the contents back
5. Tool call to send was preceded by a long task with active streaming output

Failure mode #2 is somewhat suggestive of a model-side issue (Sonnet 4.6 substituting a Bash stub for a SendMessage call), but the surrounding context is identical to mode #1, so they may share an upstream cause in how Claude Code's subagent runtime serialises long contexts before tool dispatch.

Diagnostics attached

• diagnostics.txt — claude/tmux/macOS versions, run-dir contents, team config
• iter1-stack-trace.txt — reconstructed stack frames from the iter-1 crash
• pane-103-iter2-scrollback.txt — full live scrollback of the iter-2 silent-drop incident
• review_2.md — the review the teammate produced and never delivered (recovered from disk by orchestrator)

Workaround we're using

Orchestrator manually polls tmp/codex_reviews/runs/*/review_N.md after dispatching a codex-reviewer subagent. When the teammate goes idle without a SendMessage, read the review file directly. Adds ~30s of operator attention per review iteration but is robust.

What we'd like

1. Confirm whether SendMessage failures in tmux subagent panes are a known issue and which Claude Code release fixes them.
2. Diagnostic surface: a way to detect "teammate model decided to emit a tool call but the call did not reach the bus" — e.g., a synthetic delivery log the orchestrator can consult.
3. Fail-loud behavior for failure mode #1 — if the Ink renderer crashes, write a marker file or exit the pane process with a non-zero status so the orchestrator can respawn, instead of leaving a hung pane.

Happy to provide more diagnostics if useful. Project repo is private but we can share scrubbed scrollback / config files separately.