Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Intermittent "Tool permission stream closed before response received" on Bash tool calls

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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.

Error Message

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.

  • Not an allowlist denial (no "permission denied" error; approval never completed in either direction)
  • Not a sandbox block (no sandbox error surface)

Error Messages/Logs

Root Cause

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.

Code Example

## 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.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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 patternFailures
git (status, add, commit, diff)9
./deploy.sh (git + SSH + PM2 chain)4
ssh / scp to a remote host3
gh api with an inline ssh subcall1
node -e inline script1
grep with complex quoting1

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

extent analysis

TL;DR

The most likely fix is to modify the permission broker to either return a decision before closing the IPC channel or retry internally before surfacing failure to the model.

Guidance

  • Investigate the permission broker's behavior when handling Bash tool calls that spawn subprocesses, focusing on network interactions and longer-running commands.
  • Review the code for any potential timeouts or connection closures that could cause the permission stream to close prematurely.
  • Consider adding retry logic or increasing timeouts to mitigate the issue, especially for commands like git status and ./deploy.sh.
  • Examine the correlation between 1p_failed_events telemetry entries and the failures to determine if there's a broader IPC/network condition contributing to the problem.

Example

No specific code snippet can be provided without more context, but the fix might involve modifying the permission broker's decision-making process, such as:

# Pseudo-code example
def permission_broker_decision(tool_call):
    # ... existing logic ...
    if tool_call.spawns_subprocess():
        # Introduce retry logic or increased timeout
        retry_count = 0
        while retry_count < 3:
            try:
                # Attempt to return a decision
                return decide_permission(tool_call)
            except TimeoutError:
                retry_count += 1
                # Wait and retry
                time.sleep(1)
        # If all retries fail, surface the failure
        raise PermissionError("Failed to obtain permission")

Notes

The issue's non-deterministic nature and lack of clear reproduction steps make it challenging to provide a definitive fix. Further investigation and logging may be necessary to fully understand the root cause.

Recommendation

Apply a workaround by introducing retry logic or increasing timeouts in the permission broker, as the root cause is not entirely clear and may require additional debugging.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

#api#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Intermittent "Tool permission stream closed before response received" on Bash tool calls