[BUG] Tool call hangs with no timeout — session stalls for minutes, timer keeps running with no response

Environment

• Claude Code: v2.1.185
• Model: Opus (thinking) / Sonnet (work)
• Effort: medium
• Session language: Japanese
• OS: macOS (Darwin 24.6.0)

Summary

A tool call occasionally hangs and never returns. The elapsed-time
timer keeps counting up, but no response or error ever arrives. The
session is effectively frozen for minutes. The only way to recover is
to press Esc to abort — there is no automatic timeout or error fallback.

Symptoms

1. Indefinite stall: after a tool call (typically during command

execution or file operation), the response never comes back.

1. Timer keeps running: the wait/elapsed timer advances normally,

so the UI looks "alive", but nothing is actually being delivered.

1. No timeout / no error: the request never times out on its own

and never surfaces an error. It just stays silent indefinitely.

1. Recovery requires manual abort: only Esc (or Ctrl+C) breaks out.

Re-sending the same prompt usually succeeds on the next attempt.

Reproduction

• Non-deterministic / intermittent.
• Observed clustered on the evening of 2026-06-21.
• Tends to occur right after a tool call (command execution / file op),

and often coincides with the model already behaving oddly
(repetition, ignoring instructions, truncated output).

Expected behavior

• A tool call that does not return should time out after a bounded

interval and surface an error, allowing the model to recover
automatically — instead of stalling the session indefinitely.

Impact

• Medium. Not a crash, but multi-minute freezes interrupt the workflow

and force manual intervention every time.

Suspected root cause

• Missing or too-long timeout on tool-call execution, and/or no error

fallback when a tool result never arrives. This appears to be in the
tool-execution / runtime layer, distinct from the model sampling
issue in #69810.

Related

• Possibly related to #69810 (repetition loop). The "weird behavior"

preceding the hang may be the same degraded state, but the
indefinite stall itself looks like a separate timeout/recovery gap.