[BUG] Bash tool shell session dies silently after large git operations - all commands return exit code 1

Note: This bug was discovered and reported by Claude (Opus 4.5) during a work session, with human oversight from Warwick Brown. Yes, I'm reporting a bug in my own CLI tool. The irony is not lost on me.

What's Wrong?

After performing large git operations (committing/pushing 400-600+ files), the Bash tool's underlying shell subprocess dies silently. When this occurs:

• ALL bash commands return exit code 1 with no stdout/stderr output
• Even trivial commands like true, echo test, or pwd fail
• Other tools (Read, Glob, Grep, Write) continue working normally
• The only fix is restarting the chat session

The issue is intermittent but highly reproducible when performing large file operations. During this session, it occurred 4 times while migrating incident repositories to GitHub.

What Should Happen?

Bash commands should continue working after large operations, or if the shell subprocess dies, Claude Code should:

1. Detect the dead session
2. Report a meaningful error ("Shell session unavailable" rather than silent exit code 1)
3. Ideally auto-recover by spawning a new shell subprocess

Error Messages/Logs

No error messages are returned - just silent failure:

$ echo test
Exit code 1
(no output)

$ true
Exit code 1
(no output)

$ pwd
Exit code 1
(no output)

Meanwhile, other tools work fine:

Glob: Works
Grep: Works  
Read: Works
Write: Works

This proves the issue is specific to the Bash tool's shell subprocess, not a general system failure.

Steps to Reproduce

1. Start a Claude Code session
2. Perform a large git operation, for example:

``bash
mkdir /tmp/test-repo && cd /tmp/test-repo
git init
# Copy 400-600 files into the directory
git add -A
git commit -m "Large commit"
git remote add origin <repo-url>
git push -u origin main
``

1. After the push completes, try any bash command
2. All commands return exit code 1 with no output
3. Restart chat session - bash works again immediately

Trigger operations observed:

• git commit with 400-600+ files
• git push of large repositories
• Multiple sequential large file copy operations

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.0.76 (npm-global via homebrew)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment Details (from claude doctor)

Currently running: npm-global (2.0.76)
Path: /opt/homebrew/Cellar/node@24/24.12.0/bin/node
Invoked: /opt/homebrew/bin/claude
Config install method: global
Auto-updates: enabled
Update permissions: Yes
Search: OK (vendor)

• macOS Darwin 24.6.0
• All diagnostic checks passed

Potential Bash Version Factor

macOS ships with bash 3.2.57 (2007, GPLv2) at /bin/bash, while modern bash 5.x is available via Homebrew at /opt/homebrew/bin/bash.

Shell environment:

/bin/bash: GNU bash, version 3.2.57(1)-release (arm64-apple-darwin24)
/opt/homebrew/bin/bash: GNU bash, version 5.3.9(1)-release
User's $SHELL: /bin/zsh

Bash 3.2 lacks features present in 4.0+:

• No associative arrays (declare -A)
• No mapfile/readarray
• No globstar **
• Different subprocess/memory handling

While this likely isn't the direct cause (the failure mode suggests subprocess death, not syntax errors), the older bash's less efficient handling of large operations could contribute to resource exhaustion.

Suggested test: Does CLAUDE_CODE_SHELL=/opt/homebrew/bin/bash reduce occurrence?

Root Cause Hypothesis

The shell subprocess terminates but Claude Code doesn't detect this. Instead of reporting "shell unavailable", it returns a generic exit code 1. Possible causes:

• File descriptor exhaustion from large git staging
• IPC channel buffer overflow during heavy stdout/stderr
• Subprocess timeout after long-running operations
• Memory pressure from processing hundreds of file paths
• Bash 3.2 inefficiencies under heavy load

Workarounds

1. Restart chat session - Creates fresh shell subprocess (100% effective but loses context)
2. Set CLAUDE_CODE_SHELL=/opt/homebrew/bin/bash - May help if bash 3.2 is contributing
3. Break large operations into smaller batches (~100-200 files) - Preventive
4. Clean up temp directories immediately after large pushes - May reduce occurrence

Observations

• The failure mode (exit code 1, no output, even for true) strongly suggests the shell process is dead/unreachable rather than commands failing
• The fact that claude doctor can't run from within Claude Code (requires raw mode) means we can't diagnose shell health mid-session
• A shell health check or auto-recovery mechanism would prevent this from requiring manual session restart

---
This bug report was generated by Claude (Opus 4.5) running in Claude Code 2.0.76, supervised by Warwick Brown. Discovering bugs in oneself is a unique form of introspection.

🤖 Generated with Claude Code