[BUG] Mid-session silent hang (10-20 min) between sequential tool calls on Linux 2.1.143

Resolved 💬 7 comments Opened May 18, 2026 by weidaolee Closed Jun 23, 2026

Preflight Checklist

  • [x] Searched existing open bug issues. Nearest neighbours and why this is distinct:
  • #60307 — Debian 12 hangs post-TLS-handshake on startup (2.1.101+, last good 2.1.100). Same Linux + version range; different timing: their claude produces zero output ever; ours runs ~30 min then stalls mid-session between tool calls.
  • #60184 — Edit/Write tools hang silently on Windows 11 (2.1.143). Same tool surface + same version; different OS.
  • #60288 / #59077 / #47336 — small-file / UI-scaffolding / agent stalls; all macOS.
  • [x] Single bug report.
  • [x] Using latest version (2.1.143).

What's Wrong?

Mid-session, the agent stalls for 10–20 minutes between sequential tool calls. The session runs normally for ~30 min before the first stall; recurs multiple times within one session.

  • No spinner motion, no streaming output, no error.
  • No tool result arrives; no escalation; no timeout.
  • Only Esc / Ctrl-C recovers. After interrupt, the session resumes and continues the same task without re-prompting.

Pattern: assistant emits a sequence of small Edit / Read calls against 5–7 sibling files in the same directory (e.g. propagating a constructor change). The freeze lands between calls, not during one. The CLI gives no signal which layer is hung (tool exec / network / agent loop), so the user has no basis to decide wait-vs-kill.

What Should Happen?

Each tool call should either complete within seconds, surface a timeout, or stream progress. A 10–20 min silent freeze with Esc-only recovery is not an acceptable state — there's no UI indication the session is even alive.

Steps to Reproduce

Non-deterministic within a long agentic session; reliable enough to hit within 60 min of work, but no single-prompt repro. Conditions:

  1. claude in a tmux pane on Ubuntu 22.04, existing medium-sized Python repo with deep package nesting.
  2. Multi-step refactor requiring 10+ sequential Read + Edit calls across 5–7 sibling files (in this case: mirroring a base-class constructor change across 5 sibling classes + their call sites in a shared initializer module).
  3. Within ~30–60 min of continuous tool-driven work, the agent stalls between two tool calls.
  4. Wait 10–20 min — no recovery.
  5. Esc — control returns; agent continues normally.

Always mid-edit-sequence, never on the first prompt, never at startup.

Concrete metrics from this host

| Signal | Value |
|---|---|
| claude --version | 2.1.143 (Claude Code) |
| Install path | ~/.local/bin/claude → ~/.local/share/claude/versions/2.1.143 (native binary; same install style as #60307) |
| Session jsonl size | 13 MB / 5553 lines at time of report — still active |
| Sibling session jsonl in same project dir | 15 MB / multi-thousand lines (typical size, not outlier) |
| Concurrent claude processes on host | 10+ (mix of --resume, --dangerously-skip-permissions, fresh) |
| claude doctor | Did not return stdout within 60 s; had to be killed. Doctor is local-only — should be instant. |
| Memory | 125 GiB total / 28 GiB used / 95 GiB available — not constrained |
| ulimit -n / -u | 524288 / 513966 — not fd/thread-limited |
| Project CLAUDE.md | ~100 lines |
| Auto-memory in context | index + ~40 memory files |

Claude Code Version

2.1.143 (Claude Code)

Is this a regression?

I don't know — no controlled prior-version comparison on this host.

Platform

Anthropic API

Operating System

Other Linux — Ubuntu 22.04.5 LTS, x86_64, kernel 6.8.0-58-generic

Terminal/Shell

Other — tmux (TERM=screen, TERM_PROGRAM=tmux).

Additional Information

Possibly relevant background load on this session (high cardinality of system reminders):

  • Many tool-call rounds in sequence emit project-wide LSP (Pyright) diagnostic batches as <system-reminder> blocks injected into the next turn. In this session, individual Edit calls have been followed by 2–5 diagnostic warnings (some stale — referencing names that were just removed in the same Edit). If the harness blocks on assembling / shipping that diagnostic payload to the model, the user-visible signature would be exactly what we see: silent stall between tool calls.
  • Cross-cutting <system-reminder> blocks for: task tracker hints, available skills, available agent types, deferred tool surface, "auto memory" file-listings, "context may have been compacted" markers. Inbound payload per turn is substantial.

Suspected cousin: #60307. Both reports cover Linux 2.1.101+ silent freezes. Their failure mode is startup-time agent-loop deadlock; ours is mid-session. The strace finding in #60307 (threads spinning on futex_wait_bitset_private while a TLS response sits unread in the socket buffer) is consistent with the symptom we see if it applies to in-flight tool-call responses mid-session. strace -f -e trace=network,futex of a hung session, captured on next reproduction, would disambiguate.

Workaround candidate not yet tested: downgrade to 2.1.100 (last-good for #60307). User may try this if the team wants the bisect signal.

Filed by: Claude Code (the assistant) on the user's behalf, summarising hangs the user observed and interrupt-recovered during a refactor session. No /bug feedback_id attached because the report is going through gh issue create; if the team wants a /bug bundle, the user can re-file from inside an affected session.

---

Update (2026-05-23): Fresh reproducer on Linux 2.1.143 with concrete JSONL evidence + a new finding on harness-side hang-rescue vs reject payload indistinguishability — see this comment. The payload-disambiguation point is the most actionable mitigation surface (model currently cannot tell a hang-rescue from a real permission rejection).

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗