Significant Pre-Execution Delay (~210s) When Calling Bash Tool on Windows
Status Fixed / completed
Maintainer reply ✓ Yes — ant-kurt
Activity 6 comments · opened Jul 21, 2025 · closed Jul 22, 2025
💡 Likely answer: A maintainer (ant-kurt, collaborator)
responded on this thread — see the highlighted reply below.
Description:
When using the Bash() tool within Claude Code on a Windows environment, I consistently observe a substantial delay (approximately 200-210 seconds) before the actual Bash command begins execution and before the permission prompt appears.
Steps to Reproduce:
- On a Windows 10/11 system (with Git Bash installed and its path correctly added to environment variables).
- Launch Claude Code from a PowerShell terminal (or a Git Bash tab within Windows Terminal).
- Ask Claude Code to execute any simple Bash command, e.g.:
Bash(echo "Hello")Bash(pwd)Bash(ls -la)
- Observe that Claude Code displays
Bash(...) Running...orWaiting...on the command line, and this state persists for about 200-210 seconds. - Only after this prolonged delay does the "Do you want to proceed?" permission prompt appear.
- The Bash command then actually executes only after the permission is granted.
Expected Behavior:
- Bash commands should start executing immediately (or after a very brief setup time) upon being called.
- The permission prompt should appear instantly before command execution, not after a significant delay.
Actual Behavior:
- Every call to the
Bash()tool, even for the simplest commands, consistently hangs for approximately 200-210 seconds before the command begins execution and before the permission prompt is displayed. - This makes the
Bash()tool virtually unusable on Windows due to the extreme waiting times for every single operation.
Potential Cause (Speculation):
I suspect this may be related to an underlying compatibility or process management issue within Claude Code when it attempts to launch and manage external Bash processes on the Windows platform. It appears to experience a long-term block or timeout while interacting with Windows process APIs.
6 Comments
Also seeing this exact behavior on MacOS Sequoia 15.5
Can you run with
ANTHROPIC_LOG=debugand see if you're getting failed requests to Haiku (or your customANTHROPIC_SMALL_FAST_MODELif you have set that env var)? There's a pre-flight check that needs to pass for bash commands to run, and failure of that can cause issues similar to what you're reporting.[log_f72914] post https://bedrock-runtime.us-west-2.amazonaws.com/model/us.anthropic.claude-3-5-haiku-20241022-v1:0/invoke-with-response-stream failed with status 403 in 95ms - error; not retryable[log_f72914] response error (error; not retryable) {
url: 'https://bedrock-runtime.us-west-2.amazonaws.com/model/us.anthropic.claude-3-5-haiku-20241022-v1:0/invoke-with-response-stream',
status: 403,
headers: {
connection: 'keep-alive',
'content-length': '68',
'content-type': 'application/json',
date: 'Mon, 21 Jul 2025 19:53:30 GMT',
'x-amzn-errortype': 'AccessDeniedException:http://internal.amazon.com/coral/com.amazon.bedrock/',
'x-amzn-requestid': 'f3065cc9-393c-4331-b765-8b29d5a61f77'
},
message: undefined,
durationMs: 97
}
Ah that was it! I enabled model access for Haiku 3.5 in my Bedrock env and now it's working.
Glad that fixed it for you! Checked in a helpful log message about this when the pre-flight check takes a while, to help identify this in the future.
Thank you so much! The issue is resolved. It was indeed an AWS Bedrock permissions problem. After checking and enabling model access as per your guidance, everything is working perfectly again. Really appreciate your quick response and accurate diagnosis! 🙏
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.