[BUG] Bash tool calls running shell loops stall in long headless (claude -p) sessions and are moved to the background, while the same commands finish instantly by hand

Status Open
Reported on v2.1.284
Maintainer reply None cached
Activity 0 comments · opened Sep 30, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Six times between 2026-09-16 and 2026-09-19, a Bash tool call that ran a shell loop (a for or while-read loop, or a pipeline feeding a per-item git or grep call) never returned, and the harness moved it to the background at its timeout. The headless session could not recover.

Every occurrence shares two things: the call ran a loop spawning many short subprocesses, and the session had already been running for tens of minutes. Single-command calls in the same sessions stayed instant before and after the stall.

Measurements, same host, same worktree:

  • The identical loop completed in 5.4 s in a plain shell; the same session had run it twice earlier in 3 s and 5 s, then hung for 1625 s until killed.
  • A pipeline plus per-path git ls-files loop ran 602 s in-session against 0.014 s by hand; its output file held the pipeline's first result, then [killed].
  • A nested session (claude -p inside the Bash tool) hung inside such a loop.

Ruled out by measurement:

  • Standard input: every stage has an input operand; nothing reads the tool's stdin.
  • git contention: no index.lock; 40 git ls-files calls take 0.27 s.
  • Process or descriptor limits: ulimit -u 10666, ulimit -n 1048576; two 200-iteration subprocess loops complete in a fresh session.

Possibly related, not tied to the stall: fork-heavy test suites on this host show system time above user time (real 2:22, user 52.6 s, sys 60.3 s) against 33 s on a Linux container.

Workaround in use: a PreToolUse hook forbids ad hoc loops, and multi-step checks run as one committed script per call. No loop has hung since, but the stall is unexplained.

What Should Happen?

A loop that completes in seconds by hand completes in seconds in-session, or the session reports what it is waiting on.

Error Messages/Logs

Command did not complete within its 600s timeout and was moved to the background

Steps to Reproduce

In a headless claude -p session that has been running for 20 minutes or more, issue a Bash tool call that runs a loop spawning many short subprocesses, e.g. a while-read loop over git ls-files running git show and grep per file. It stalls, while the same command run by hand completes in under a second.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

2.1.284

Claude Code Version

2.1.284

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

running headless under a GitHub Actions self-hosted runner.

View original on GitHub ↗