[BUG] Turn goes permanently idle (event loop idle in kevent64, no error): dropped tool_result, stalled compaction, or queued input never taken up (macOS, 2.1.268 to 2.1.283)

Second occurrence in the same session, same terminal state, different trigger.

The session above wedged again about 45 minutes after the first hang, following --resume. I sampled it before killing it. The main thread is in the same place, through the same frames:

hang 1   3148 / 3213  (98.0%)   +0x7ac3a8 -> +0x7abd14 -> kevent64
hang 2   3934 / 4010  (98.1%)   +0x7ac3a8 -> +0x7abd14 -> kevent64

Identical offsets, so this is the same unwakeable idle-event-loop state described in the report. CPU 1.3%, no ESTABLISHED socket.

But this time there was no orphaned tool_use at all. Every tool call had its result:

| Agent | tool_use | tool_result | orphaned |
|---|---|---|---|
| Parent session | 137 | 136 | 1, carried over from hang 1 |
| In-process teammate | 50 | 50 | 0 |

The trigger was compaction, not a tool call. The UI reached 95% and stopped there permanently. Notably, two compactions had already completed successfully earlier in the same session, so compaction is not broadly broken.

So there appear to be at least two distinct entry points into one terminal state: a dropped tool_result, and something in compaction. That is evidence for the watchdog suggestion in the report being worth doing independently of whatever drops the result, since a watchdog keyed only on pending tool_use ids would not catch the compaction case. A stall detector on the event loop having no registered work while a turn is marked in progress would catch both.

One correction to my own evidence, for anyone measuring this. grep -c kevent64 on a sample file returns 3 for a wedged process and for a healthy one, since the string appears once in the main thread, once in a helper thread, and once in the by-function summary. The meaningful figure is the main thread's kevent64 sample count over that thread's total. And a healthy session idling at the prompt also reads ~98%, so the idle stack alone does not prove a hang. It proves the process is not busy and that waiting cannot recover it; the hang is established by that idle state coexisting with a turn in progress.

Both hangs ran 2.1.270, confirmed from the (in 2.1.270) frames in sample rather than from claude --version, which reports the installed version rather than what a long-lived session is actually running.

A base rate that may help narrow the dropped-tool_result path.

Across 4,499 tool calls in the two affected sessions, Read accounts for 4.8% of all calls. The workload is dominated by an MCP search tool (32%) and Bash (27%). Yet all four dropped calls I have found are Read:

dropped call #1 of 2      Read    subagent
dropped call #1 of 1      Read    subagent, first call of its life
dropped call #7 of 8      Read    in-process teammate
dropped call #71 of 181   Read    parent session

Under a null where drops fall uniformly across tool calls, p is about 5e-6. Collapsing the two that were retries of the same task into a single independent event still gives about 1e-4. Four events is a small sample and I would not read the exact figure too hard, but Read is over-represented far beyond chance, which points at the file-read completion path specifically rather than general tool dispatch.

Two things I checked and ruled out, so nobody spends time on them:

• Not the file. Two of the drops targeted the same 54,515-byte JSON file. That same file was read successfully twice, two days earlier, in the same session. Ordinary JSON, longest line 309 characters, and siblings up to 3.1MB read fine throughout.
• Not position in the session. The drops occurred at call #1, #1, #7 and #71 of their respective agents, so this is neither a startup nor a long-session effect.

Also worth correcting a measurement trap in my original report, for anyone trying to reproduce the analysis: grep -c kevent64 on a sample file returns 3 for a wedged process and for a perfectly healthy one alike, because the string appears once in the main thread, once in a helper thread, and once in the by-function summary. The meaningful figure is the main thread's kevent64 sample count as a share of that thread's total samples.

Correcting my own statistic above, and replacing it with something stronger.

My earlier comment claimed all four dropped calls were Read at p about 5e-6. That figure was wrong and should be disregarded. It compared drops against Read's 4.8% share within the two sessions I had selected because they contained drops -- a circular denominator. I have now run the census across my whole local corpus instead.

Corrected numbers. 276 transcripts, 21,005 tool calls. 12 orphaned tool_use ids exist, but only 7 are provably dropped, meaning later calls were issued and returned while that result never arrived. The other 5 are last-call orphans, which are indistinguishable from a call still in flight. By tool:

| Tool | Provable drops | Share of all 21,005 calls |
|---|---|---|
| Read | 4 | 11.71% |
| mcp__github__pull_request_read | 2 | (both in one agent) |
| Bash | 1 | 51.02% |

So Read is still over-represented and Bash strikingly under-represented, but the honest figure is p about 0.005, weaker still under clustering, and drops are not exclusively Read. Base rate of the bug overall: 0.033% of calls.

The stronger finding: a dropped result is not survivable. It kills the agent it lands in.

I had assumed these agents shrugged the drop off, because sibling calls issued in the same batch returned afterwards. They did not. Looking at how each transcript ends:

196 subagent transcripts
189  (96.4%)  end with an assistant text message   <- the agent's finished report
  7  ( 3.6%)  end abruptly on a tool_result or an unreturned tool_use

5 of those 7 abrupt endings have an unreturned read-type call. The agents did not continue and never reported. Two further details:

• Controlled for the obvious confound. An abrupt tail would also be produced by killing the process. It was not that: each affected agent's parent session went on working for 1778 to 2032 further turns, in two cases across two more days. The agent died alone while its parent lived on.
• One of the 7 is the retry of another. The same task was attempted twice and both attempts died on an unreturned Read.

Why this is invisible in practice, which I think matters for the fix. All 7 were background agents. The Agent/Task tool returns "Spawned successfully" immediately, and that string is the tool_result. So the parent's tool_use/tool_result census balances perfectly regardless of what happens to the agent afterwards. No completion notification arrives, no error is recorded, isApiErrorMessage is 0. The requested work simply never lands and nothing anywhere says so.

That argues the watchdog I suggested earlier has to live inside the agent loop, not in the parent's pending-tool_use bookkeeping, because parent-side bookkeeping cannot observe this failure even in principle.

Two measurement traps, for anyone reproducing this analysis:

• A pending AskUserQuestion is indistinguishable from a hang. It leaves exactly one orphaned tool_use and a main thread ~98% parked in kevent64. I called a healthy session wedged on this basis earlier today; it was waiting on a question it had asked. Check whether the last orphan is AskUserQuestion before concluding anything.
• A correlation I chased and had to discard: two of the abrupt agents died immediately after SendMessage, which looked meaningful until I checked the base rate. SendMessage is the last tool call in 49.5% of agents that finish normally, because that is how an agent reports back. Dying after one is less likely than chance. Not a lead.

Counts, percentages and timestamps are unmodified. Paths, repository names and session ids are omitted or replaced.