claude-code - 💡(How to fix) Fix Tool dispatch stall: tool_use emitted, no tool_result, no permission-stream error (CLI 2.1.121-2.1.123)

Summary

claude CLI 2.1.121-2.1.123 occasionally emits a tool_use block to the assistant stream, but the internal dispatch IPC stalls before invoking the tool handler. The tool never runs, no tool_result is ever produced, no permission-stream error is emitted. The CLI session sits dead until killed by an external watchdog or the user gives up.

We see this ~22 times/day on a single workstation across normal usage — Write, Bash, Edit, and Read tools all affected.

Reproduction signature (after-the-fact, deterministic to detect)

In the session JSONL at ~/.claude/projects/<project>/<sessionId>.jsonl:

1. A tool_use block exists in the assistant stream with a given tool_use_id.
2. No tool_result entry ever appears for that tool_use_id.
3. No Permission stream broken event in surrounding logs (this is what distinguishes from the older perm-stream regression class).
4. Target file/command side-effects do not occur on disk — verified by sampling 5 stuck Writes; 4/5 targets did not exist, 1/5 was from an unrelated later retry with different content.

We don't have a tight in-process repro yet — happens stochastically across all tool types under normal interactive load. Happy to instrument further on request.

What it's NOT

This is not the older permission-stream regression (`reference_claude_cli_permission_stream.md` class). That class emits `Permission stream broken` events and was empirically patched by ~2.1.121. This dispatch-stall class is silent — no error markers anywhere, just absent `tool_result`.

Versions affected

• 2.1.121: confirmed
• 2.1.122: confirmed
• 2.1.123: confirmed

Have not tested 2.1.120 directly for this specific class but suspect it's a regression introduced when the perm-stream patch landed.

Mitigation in use locally

External watchdog (in our agent harness) kills the subprocess after a per-tool-type timeout (240s for fast tools, 600s for heavy tools), then asks the model to retry. This recovers but costs ~5 min wall-clock per incident plus dropped tool work and a partial-output orphan.

What would help

• Confirmation this is a known regression, or guidance on instrumenting to capture stack traces.
• If reproducible internally, a fix in the dispatch IPC.
• If not, a CLI-level timeout + recovery so the watchdog isn't the only escape.

Filed on behalf of an OpenClaw user (the agent harness this was reproduced against). Happy to share full session-JSONL examples privately if useful — just ask.