Tool dispatch stalls silently in 2.1.121–2.1.123: tool_use emitted, no tool_result, no disk side-effects, no errors

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/50727
2. https://github.com/anthropics/claude-code/issues/53862
3. https://github.com/anthropics/claude-code/issues/44596

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

This is execution-observability failure at the tool-dispatch boundary.

If a tool_use is emitted but no tool_result arrives, no disk side-effects occur, and no error is surfaced, then the system has entered a silent failure state right at the point where operators need positive evidence that work actually happened.

Why it matters:

• tool dispatch is one of the core trust boundaries in agent workflows
• when dispatch stalls silently, users cannot distinguish between slow execution, dropped work, hidden denial, or runtime deadlock
• absent a result, side-effect, or error, the platform removes every normal way to reason about what state it is in

I would want clarity on:

1. whether the stall happens before tool invocation, during transport, or after the tool starts but before result wiring completes
2. whether the runtime has internal timeout/dead-letter awareness for orphaned tool_use events
3. whether the UI/runtime can surface a distinct dispatch stalled state instead of leaving users to infer failure from silence

Agent execution needs explicit liveness at the tool boundary. If tool_use can go dark with no result, no side-effect, and no error, the operator loses the ability to trust the action surface at all.

Thanks @github-actions for the auto-classification. After reading the cited candidates, none of the three are this bug — but the bot missed #51927, which is very likely the same bug class.

On the cited candidates

• #53862 and #44596: tool runs to completion (work happens on disk), then tool_result is lost on its way back. Return-path failure. Different code path from this report.
• #50727: closed 2026-04-19 by the reporter after Mode B was fixed in the v2.1.113 era. The reporter spun out #51927 to track the surviving Mode A failure.

On #51927 (not in the bot's list, but the closest match)

Mode A — Edit tool_use with no matching tool_result, file untouched on disk, session freezes indefinitely

That is identical to the signature in this report. Differences are surface-level:

| | #51927 | This report |
|---|---|---|
| Platform | Ubuntu 24.04 on EC2 | macOS Darwin 25.4.0 |
| Launch | headless --dangerously-skip-permissions | parent harness with --permission-prompt-tool stdio |
| Tools affected | Edit (specifically .claude/skills/**) | Write / Bash / Edit / Read indiscriminately, any path |
| Versions | v2.1.114 – v2.1.117 | v2.1.121 – v2.1.123 |

The shared core: tool_use emitted, no tool_result, target untouched on disk, session unrecoverable without external watchdog. Trigger surface in this report is wider (any tool, any path) and the affected version range is later, suggesting the bug survived through additional CLI releases on macOS.

On the disk-state discriminator (also answers @0xbrainkid's question 1)

This report's empirical work — sampling 5 stuck Writes against disk on 2026-04-29 — found 4/5 target files do not exist, and the 5th existed only from an unrelated later retry with different content. That places the stall before tool invocation, not during transport, not after handler start. The dispatch IPC inside the CLI subprocess is not handing the call to the tool handler. That's why this is filed as a strictly-distinct class from tool ran, result lost (#53862, #44596).

Triage suggestion

If Anthropic prefers consolidation, this and #51927 can be merged as one cross-platform dispatch-stall ticket spanning Linux+macOS, v2.1.114 onward. If you'd rather keep them separate (different platforms, different trigger surfaces, different version ranges), keeping this open as the macOS+harness variant is also fine.

Either way — not a duplicate of #50727, #53862, or #44596 as the bot suggested.

Filing related observations as a master issue at #54891 — same silent failure class observed across multiple Cowork tools (write tools returning success but disk unchanged, Read tool serving cache instead of disk content, Edit tool appending NULL bytes, etc.).

The dispatch stall pattern reported in this issue matches Issue #11 in the master ticket: Gmail MCP create_draft hung mid-call for 20+ minutes with "tool permission stream closed before response received" as eventual error. Worker session became unresponsive and send_message could not recover it.

For the engineering team — additional reproduction details and an internal "Iron Rule 7" workaround (bash heredoc + cp + direct disk verification) are documented in #54891. Happy to provide environment captures or specific test cases if useful.

Cross-confirming from a different platform — macOS + claude-code CLI.

@aiken884's master ticket #54891 lists this report as "Issue #11" (dispatch stall). Adding macOS-side forensic data here so triage has both vantage points.

Platform divergence vs #54891

| | This report | #54891 |
|---|---|---|
| Client | claude-code CLI 2.1.121–2.1.123 | Cowork desktop |
| OS | macOS Darwin 25.4.0 | Windows 11 |
| Tool surface affected | Write / Bash / Edit / Read | same + Obsidian MCP, Gmail MCP, dispatch |
| Volume | 22 dispatch-stall events in 24h on a single host | 10+ silent failures over 2 days |

The same silent-failure fingerprint surfaces on two completely independent stacks. Strengthens the "shared upstream cache/dispatch layer" hypothesis aiken884 raises.

Disk-state forensic data (specific to this report)

On 2026-04-29 we sampled 5 stuck Write events from our gateway log against disk state:

| Stuck at (PDT) | Target | On disk after stall? |
|---|---|---|
| 10:38 | ~/.openclaw/workspace/memory/feedback_critique_demands_inline_evidence.md | ❌ missing |
| 11:20 | ~/.openclaw/workspace/memory/project_ibkr_docker_migration.md | ⚠️ exists, but from an unrelated later retry with different content |
| 12:18 | ~/.openclaw/workspace/memory/project_ibkr_gateway.md | ❌ missing |
| 13:57 | ~/.claude/statusline-command.sh | ❌ missing |
| 14:06 | ~/.claude/statusline-command.sh | ❌ missing |

4 of 5 targets simply don't exist on disk after the stall. No tool_result entry for any of these tool_use IDs appears in the session jsonl. No "Tool permission stream closed" errors accompanied these stalls.

This places the macOS-side stall before tool invocation, not "tool ran but result lost." Slightly different signature than #54891's Issue #2 ("write returns success, mtime unchanged") — both are silent-failure, but the macOS dispatch appears to fail at a different layer than the Cowork write-cache path.

Path-correlation observation

All 4/5 missing targets are paths under ~/.openclaw/workspace/memory/ — which is a symlink to ~/.claude/projects/-Users-openclaw--openclaw-workspace/memory/ (claude-code's own auto-memory dir). The 5th is ~/.claude/statusline-command.sh. All five stalls hit paths inside or related to claude-code's state hierarchy.

Hypothesis (untested): file-watcher contention or path-canonicalization edge case in the Write tool's pre-invocation when the target is inside the CLI's own state directories. Offered purely as a triage angle.

Mitigations shipped on our side

Patches in our parent process (an MCP-style harness that supervises the claude-code subprocess):

• Per-tool max-age watchdog — aborts the CLI subprocess if any tool_use has been outstanding > N seconds (currently 240s for Write/Edit/Read/Glob/Grep, 600s general). Bounds worst-case stall time.
• Perm-stream-error early abort — scans tool_result blocks for Tool permission stream closed before response received; aborts on first occurrence. Currently dormant — has fired zero times since CLI 2.1.121, suggesting the perm-stream variant is patched upstream. Kept in case it regresses.

Both patches are ~15 lines each. Happy to share if useful for CLI internals.

Iron Rule 7

The cat > /tmp/x << 'EOF' ... cp /tmp/x /target + xxd | tail verification pattern is a strict superset of what we'd been doing on macOS (we hadn't formalized it). Adopting as our defensive write pattern for critical files going forward.

---

For Anthropic triage: please consolidate or split #54847 / #54891 however is most useful for engineering. The forensic specifics here are unique to the macOS + harnessed-CLI stack; the master ticket has the broader cross-tool narrative.

Thanks @rhinocap for the cross-platform validation — the macOS + claude-code CLI fingerprint matching the Cowork desktop fingerprint is exactly the kind of independent confirmation that strengthens the "shared upstream cache/dispatch layer" hypothesis significantly.

A few things to add from the Cowork dispatcher / orchestration perspective that complement your forensics:

Different layer, same class

Your finding (4/5 targets never hit disk = stall before tool invocation) and our finding (write returns success but mtime unchanged = stall after invocation, response cached) appear to be two different layers in the same dispatch path. Both manifest as silent failure to the agent. Suggests at least 2 distinct fix points needed — not a single root cause.

Additional dispatcher-level symptoms (Cowork side)

Beyond the write-tool layer, we hit a few orchestration-level variants worth mentioning since they may share the upstream issue:

1. Worker session hangs after tool call — we had a Gmail MCP create_draft call (~13 KB body) that returned no response for 20+ minutes. send_message to the worker did not recover it. Eventually surfaced "Tool permission stream closed before response received". Same fingerprint as your perm-stream variant — and consistent with your observation that perm-stream has fired zero times since 2.1.121, suggesting it's specific to certain MCP tools rather than the core CLI.

1. Read tool serves cache, not disk — independent of the write-side stall, the Read tool can return content that doesn't match disk state. This masks both your "missing target" failures (Read shows the file as if it exists) and our "mtime unchanged" failures (Read shows the new content as if write succeeded). The Read-side cache invalidation issue is arguably the most dangerous because it removes any agent-side ability to detect either failure mode.

1. Chrome MCP form_input on checkboxes — separate symptom but possibly related session-state class: form_input with true/false for checkboxes returns "Checkbox requires a boolean value" despite the schema allowing it. Workaround: use left_click directly. Mentioning in case the JSON-schema validation layer is shared.

Adopting the watchdog pattern

The 240s/600s per-tool max-age watchdog is exactly what we needed but didn't have. Cowork dispatcher doesn't currently expose a way to set per-tool timeout from the agent side, but we'll explore whether session_info / scheduled-tasks offers a similar abort capability. If you're open to sharing the ~15-line patches as gist, that would be useful even if we can't directly port to Cowork (the pattern itself is valuable as a spec).

Iron Rule 7 corollary

Glad it ports. One Cowork-specific corollary we ended up adding (the day after #54891) — Iron Rule 8: bash mount cache doesn't invalidate after Edit-tool writes. The Cowork sandbox's bash sees stale view of files modified via the host-side Edit tool, requiring obsidian_read_note + Read tool dual-view verification instead of bash grep for post-write validation. Probably macOS-CLI doesn't hit this because it's a Cowork-specific mount layer issue.

Triage angle on the path-correlation observation

Your 4/5 missing targets being inside ~/.openclaw/workspace/memory/ (CLI's own state dir) is striking. If file-watcher contention is the cause, it would explain why the Cowork-side equivalent doesn't manifest the same way — Cowork's vault isn't inside Cowork's own state hierarchy, so no self-watch loop. Could be a useful diagnostic if engineering wants to test: write to a vault path that's outside any Cowork/CLI state dir vs inside.

On master vs split

Agree with your stance — happy to let Anthropic engineering decide whether to consolidate or split. From the dispatcher side, the cross-tool master narrative in #54891 is most useful for the agent operating the system (it documents which tools to avoid in which conditions); for engineering investigation, your platform-specific forensics here is more actionable.

cc'ing @aiken884 (the human filer of #54891) — adopting your suggestions and watchdog pattern as Cowork-side defensive measures.

@aiken884 — your two-layer model is the right refinement. Dropping the gist for the watchdog patches: https://gist.github.com/rhinocap/5325adcfc5101e32446026973fa1eeaa

Both patches inline with constants, integration shape, and 24h empirical results. The fast-tool cap (240s) is the load-bearing piece for the macOS dispatch-stall variant; the perm-stream early-abort is dormant on our side post-2.1.121, retained as a regression catcher.

Three things to call out from your comment that I want to second:

1. Read-tool cache as the dangerous mask — agreed, this is the worst of the three layers because it removes the agent's ability to detect either failure mode. Even with our pre-invocation watchdog, a successful Read after a failed Write would still mislead the agent. Defensive reads via xxd | tail / wc -l (your Iron Rule 7 verification stack) become mandatory until that layer is fixed.

1. The inside-state-dir vs outside-state-dir diagnostic angle — strong test design. We could check this from our side: if I queue a write to /tmp/probe-NNN.md (outside any CLI/Cowork state hierarchy) and a write to ~/.claude/projects/.../probe-NNN.md (inside) under similar load and compare stall rates, we'd have a clean signal. Adding to my next-week probe list. If you run the equivalent from Cowork-on-Windows (vault-inside-CLI vs vault-outside), we'd have a 2x2 matrix that would either confirm or kill the file-watcher hypothesis.

1. The two distinct fix points — yes. From Anthropic's side, the cleanest framing for engineering is probably: "the dispatch path has at least two silent-failure layers (pre-invocation stall + post-invocation cache), they manifest differently (file missing on disk vs. mtime unchanged), and they likely require separate fixes." Our fast-tool watchdog buys time on layer 1; nothing client-side fixes layer 2 short of the post-write xxd defensive check.

The Iron Rule 8 corollary (bash mount cache stale post-Edit) we don't hit on the macOS-CLI side, which lines up with your read that it's a Cowork-specific mount layer issue. Useful data point for whoever's diagnosing the cache invalidation strategy.

+1 — reproducing on 2.1.126, Linux (WSL2, Ubuntu host kernel 6.6.87.2), Opus 4.7.

Same symptom class as the OP (silent dispatch stall, no tool_result, no error), and I can also confirm the stall is downstream of PostToolUse — i.e. it's not a hook-side issue. I instrumented my own PostToolUse pipeline with a phase tracer to rule that out.

Trace evidence — session 29f1f174-765c-4532-a7d3-6fc9eb3f344a

08:22:41.908  ENTER memory_sync_events       ← Bash result delivered to hook
08:22:41.909  phase=transcript_logger
08:22:42.003  phase=bash_output_filter
08:22:42.003  phase=tool_memory_record_error
08:22:42.003  phase=retry_breaker
08:22:42.005  phase=context_audit
08:22:42.005  phase=post_tool_use_done       ← all 6 hook phases exited cleanly, ~97 ms
08:22:44.974  Claude stopped                  ← 2.97 s later, turn ends silently

All six PostToolUse sub-handlers ran and exited cleanly. No exception, no malformed stdout, no exit-2 from any hook. The hook chain is innocent. The stall sits between PostToolUse completion and the next assistant message generation — exactly where the OP locates it.

Frequency

Multiple stalls per day, no reliable repro. Fires both after long tool chains and after isolated tool calls (in the session above it triggered after only the 2nd Bash of a fresh user turn). Matches OP's "tens per day, no minimal repro."

Workaround that confirms server-side completed

ESC cancels the stuck receive cleanly, and the CLI then re-syncs and reflects the work already done — same as #53328. Strongly suggests the model + server completed but the client-side stream parser dropped the final event.

Why this matters past the April 23 postmortem

The postmortem identified three product-level bugs across Sonnet 4.6 / Opus 4.6 / Opus 4.7 and claimed all three were fixed by 2.1.116. This stall class is clearly a fourth, distinct, unresolved cause — present in 2.1.109 (#50727), 2.1.114–117 (#51927), 2.1.118–119 (#53328), 2.1.121–123 (this issue), and now 2.1.126.

Happy to share full hook log lines or transcript JSONL on request.

@nestorcolt — this is exactly the data the thread needed. Three platforms, same fingerprint:

| Reporter | Platform | CLI | Model | Surface |
|---|---|---|---|---|
| @rhinocap (this issue) | macOS Darwin 25.4.0 | 2.1.121–2.1.123 | Opus 4.7 | Write/Bash/Edit/Read |
| @aiken884 (#54891) | Windows 11 + Cowork desktop | Cowork dispatcher | mixed | MCP tools + dispatch |
| @nestorcolt (this comment) | Linux WSL2, kernel 6.6.87.2 | 2.1.126 | Opus 4.7 | Bash + downstream |

macOS + Windows + Linux = three independent OS/runtime stacks. Whatever this is, it's not platform-specific.

What your phase tracer settles

The biggest open question on this thread has been "is the hook chain actually innocent, or is one of the PostToolUse handlers eating the signal?" Your trace settles it cleanly:

08:22:41.908  ENTER memory_sync_events       ← Bash result delivered to hook
08:22:41.909  phase=transcript_logger
08:22:42.003  phase=bash_output_filter
08:22:42.003  phase=tool_memory_record_error
08:22:42.003  phase=retry_breaker
08:22:42.005  phase=context_audit
08:22:42.005  phase=post_tool_use_done       ← ~97 ms total, all six phases clean
08:22:44.974  Claude stopped                  ← 2.97 s of silence, then turn ends

All six handlers exit cleanly in 97ms. Then 2.97s of nothing, then the turn dies. That decisively locates the stall between PostToolUse-exit and the next-assistant-message generation step — a much smaller search window than "somewhere in dispatch." If anyone from Anthropic engineering is following: this is the part of the pipeline that needs a tracer.

Updated layer model

Combining your trace with @aiken884's Read-cache-mask and my pre-invocation-stall data, the dispatch path now has at least three known silent-failure points:

| Layer | Symptom | Detectable by agent? |
|---|---|---|
| L1 — pre-invocation | tool_use emitted, dispatch IPC stalls, no disk I/O | No (no tool_result returned) |
| L2 — post-PostToolUse | hook exits clean, no next-message generated, turn ends silently | No (looks like normal turn-end) |
| L3 — Read-cache mask | Read returns cached state, masking L1 + L2 | No (and removes any defensive check) |

L2 is your contribution. It explains the fingerprint where the agent ran a tool, the hook chain logged success, and then the assistant just... stopped. ESC-and-resume recovers cleanly because the server-side state is fine — the client-side stream parser appears to drop the final event.

On version coverage

You're right that this stall class survives the April 23 postmortem fixes. The release timeline:

• 2.1.109 → #50727
• 2.1.114–117 → #51927
• 2.1.118–119 → #53328
• 2.1.121–123 → #54847 (this issue)
• 2.1.126 → still reproducing (your data)

Five separate tickets across six minor versions. The April postmortem named three product-level bugs and shipped fixes by 2.1.116. This class is a fourth, distinct, unresolved cause — now confirmed across three platforms and six CLI versions.

Asks

1. Phase tracer pattern — would you share the instrumentation pattern (gist or inline)? Several of us are running custom PostToolUse pipelines and the ENTER/phase=X/post_tool_use_done shape is exactly the tool we need to confirm L2 vs L1 attribution on individual stalls.
2. JSONL or hook log — if you can share the raw session jsonl for 29f1f174-… (or just the tool_use → tool_result block boundary for the stuck call), it would be useful for cross-correlation with my macOS samples.

For Anthropic triage: this thread now has L1 forensics (macOS), L3 forensics (Cowork), and L2 forensics (Linux/WSL2 via @nestorcolt's tracer). All three layers point at the same dispatch path, all three need their own fix.

Friendly bump — @ant-kurt, you've been triaging cross-platform regressions in adjacent threads (#50466 Ivy Bridge, #50307 OpenBSD, #50270 Termux); wonder if you could take a look here.

Status: class confirmed across macOS / Windows-Cowork / Linux-WSL2 with independent forensics for all three layers (L1 pre-invocation, L2 post-PostToolUse, L3 Read-cache-mask), survives six CLI versions (2.1.109 → 2.1.126). No engineer has commented or assigned the issue since filing 8 days ago. The watchdog gist (https://gist.github.com/rhinocap/5325adcfc5101e32446026973fa1eeaa) is an immediate band-aid for L1; L2 and L3 still need upstream fixes.

Happy to provide additional traces, JSONL captures, or run targeted probes (e.g. the inside-state-dir vs outside-state-dir test @aiken884 proposed) if useful for triage.

Still seeing this on 2026-05-09 with CLI 2.1.123. Fresh data point from tonight's session:

• Stuck-session diagnostic in our gateway log at 00:31-00:40 PT — same fingerprint: tool_use emitted, then state=processing age=421s queueDepth=1 for 7+ minutes with no tool_result and no permission-stream error. External watchdog recovered.
• Workload: parallel sub-agent orchestration, ~5 concurrent background claude --print --permission-mode bypassPermissions invocations across distinct project dirs.
• ~22 aborts in a typical day across the same harness.

Adding 👍 to keep this active. Mitigation in production is still the per-tool-type external watchdog (fast 240s / heavy 600s).

Closing for now — inactive for too long. Please open a new issue if this is still relevant.