[BUG] Intermittent "Tool permission stream closed before response received" on Bash tool calls

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?

Summary

The Bash tool intermittently fails with Tool permission stream closed before response received. The error is transient (retry always succeeds), but in one long-running session I hit it 19 times across 5 days, all on Bash calls that spawn subprocesses running longer than a trivial moment. Other tools (Read, Edit, Grep, Glob) never trigger it.

The tool call never executes — no partial side effects — so the behavior is safe, just disruptive.

Environment

• Client: Claude Desktop, version 2.1.111 (build 2026-04-16)
• Platform: macOS (darwin, arm64)
• Node: v24.3.0, running under Bun
• MCP tools loaded: 54
• Entrypoint: claude-desktop, is_interactive: false, terminal: non-interactive

What triggers it

From one session's transcript, grouped by command type:

| Command pattern | Failures |
|----------------------------------------|---------:|
| git (status, add, commit, diff) | 9 |
| ./deploy.sh (git + SSH + PM2 chain) | 4 |
| ssh / scp to a remote host | 3 |
| gh api with an inline ssh subcall | 1 |
| node -e inline script | 1 |
| grep with complex quoting | 1 |

Common factor: Bash tool calls that spawn subprocesses touching the network or running past a short threshold. Fast local calls (ls, simple cat) and non-Bash tools (Read, Edit, Grep, Glob) do not trigger it.

What it's NOT

• Not an allowlist denial (no "permission denied" error; approval never completed in either direction)
• Not a sandbox block (no sandbox error surface)
• Not a failure of the underlying command (it never ran)
• Not user-facing — the command is simply discarded mid-approval

Expected behavior

The permission broker should either (a) return a decision before closing the IPC channel, or (b) retry internally before surfacing failure to the model.

Actual behavior

The permission stream closes before any decision is returned. The tool is reported as failed; the model has to decide to retry.

Reproduction

Not deterministic. Runs of ./deploy.sh (which chains git → ssh → pm2 restart) and git status in a large repo are the most frequent triggers in my setup. Every failed call succeeded on immediate retry with no changes.

Additional context

• Session had ToolSearch active and 54 MCP tools loaded — may be relevant if the permission broker is waiting on tool-search metadata before deciding.
• The failures cluster on heavier Bash invocations but not exclusively on long ones — git status alone has failed.
• Correlating telemetry shows 1p_failed_events entries in the same wall-clock window as some failures, suggesting a broader IPC/network condition on the client at those moments.

Happy to share a session ID privately if useful for log correlation.

What Should Happen?

Expected behavior

The permission broker should either (a) return a decision before closing the IPC channel, or (b) retry internally before surfacing failure to the model.

Error Messages/Logs

## Reproduction
Not deterministic. Runs of `./deploy.sh` (which chains git → ssh → pm2 restart) and `git status` in a large repo are the most frequent triggers in my setup. Every failed call succeeded on immediate retry with no changes.

## Additional context
- Session had ToolSearch active and 54 MCP tools loaded — may be relevant if the permission broker is waiting on tool-search metadata before deciding.
- The failures cluster on heavier Bash invocations but not exclusively on long ones — `git status` alone has failed.
- Correlating telemetry shows `1p_failed_events` entries in the same wall-clock window as some failures, suggesting a broader IPC/network condition on the client at those moments.

Steps to Reproduce

Reproduction

Not deterministic. Runs of ./deploy.sh (which chains git → ssh → pm2 restart) and git status in a large repo are the most frequent triggers in my setup. Every failed call succeeded on immediate retry with no changes.

Additional context

• Session had ToolSearch active and 54 MCP tools loaded — may be relevant if the permission broker is waiting on tool-search metadata before deciding.
• The failures cluster on heavier Bash invocations but not exclusively on long ones — git status alone has failed.
• Correlating telemetry shows 1p_failed_events entries in the same wall-clock window as some failures, suggesting a broader IPC/network condition on the client at those moments.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.3109.0 (35cbf6) 2026-04-16T20:32:01.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_