[BUG] Background Bash tool calls produce 0-byte output — shell processes never receive commands (v2.1.136)

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?

Background Bash tool calls never execute. The CLI spawns a shell process connected via a Unix socketpair, but the command is never written to the socket. The shell blocks on read(0, ...) indefinitely, the .output file stays at 0 bytes, and the model either retries in a loop or blocks on TaskOutput forever.

This is 100% reproducible across multiple independent sessions on this machine.

Likely the same underlying issue as #16431, #17540, #30786, and #20679, all of which were auto-closed for inactivity without a fix.

What Should Happen?

Cursor CLI using Claude models does not hang, so Claude CLI should not hang as well.

Error Messages/Logs

Steps to Reproduce

Environment

• Claude CLI version: 2.1.136
• OS: Almalinux 8 (Linux 4.18.0-477.27.2.el8_8.x86_64)
• Shell: zsh (from PATH) / bash (from $SHELL)
• Filesystem: NFS-mounted home directory (/net/...)
• Repo: Large git repo (~500k files, sparse checkout at 58%)

Reproduction

1. Start claude in a large repository
2. Give it any prompt that triggers a Bash tool call (e.g., "review this branch against master")
3. Observe that Bash commands show ⎿ Running in the background (↓ to manage) but never return output
4. The model retries with different commands, all failing the same way
5. Eventually the model calls TaskOutput with block: true and hangs indefinitely in "Mulling" state

Evidence

Shell processes spawned but never receive commands

$ pstree -p <claude_pid>
claude(2135702)─┬─zsh(2137534)
                ├─zsh(2137970)
                ├─zsh(2139127)
                ... (10 total)

Every shell:

• Is sleeping, blocked on read(0, ...) (confirmed via strace)
• Has no child processes (the command never ran)
• Has stdout/stderr pointing to a .output file that is 0 bytes
• Has stdin connected to a Unix socketpair back to the claude process

All output files are 0 bytes

$ wc -c /tmp/claude-*/.../.../tasks/*.output
0 bgg5p5831.output
0 bh0xa45pp.output
0 bdn8jje2x.output
... (all 0 bytes, 10 files)

Socket send queues are empty

$ ss -xp | grep claude
u_str ESTAB 0 0 ... users:(("claude",pid=2135702,fd=38))

send_q=0 on all of Claude's socket file descriptors — nothing was ever queued to send to the shells.

Strace confirms shells are waiting for input

$ strace -p <zsh_pid> -e trace=read,write
strace: Process 2137534 attached
read(0,

Blocks indefinitely. The command was never written to the socket.

Reproducible across sessions

Two independent sessions (PIDs 2050830 and 2135702) both exhibit the same behavior. The older session had been running for 3.5+ hours with its shell stuck in the same state.

Impact

• Every background Bash tool invocation silently fails
• The model wastes tokens retrying and eventually blocks forever
• Sessions become completely stuck (25+ minutes of "Mulling" with no progress)
• Resuming a stuck session (--resume) inherits the bloated conversation context and spawns new shells that also fail identically

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.136

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Not machine-specific

Cursor CLI (using Claude Opus 4.6 1M Thinking as the model) works fine on the same machine, same repo, same filesystem. Background shell execution, tool calls, and output capture all function correctly. This confirms the issue is specific to the Claude Code CLI's shell/task infrastructure, not the environment.

Additional notes

• The CLI spawns zsh (found via PATH) even when SHELL=/bin/bash is set in the environment. Setting SHELL=/bin/bash does not change the behavior.
• The hardcoded shell paths in the binary are /usr/bin/zsh, /usr/local/bin/zsh, /usr/bin/bash, /usr/local/bin/bash, but on this system zsh is at a non-standard path (~/.local/bin/zsh), found via PATH lookup.
• The NFS-mounted filesystem may contribute (latency in file operations), but the socketpair is in-kernel and should not be affected by NFS.
• Foreground/synchronous shell execution (if such a codepath exists) may not be affected — the bug appears specific to the background task machinery.