Claude’s automatically triggered Bash tool runs extremely slowly on Linux (v2.0.22)

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/6656
2. https://github.com/anthropics/claude-code/issues/10132

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This issue is not a duplicate of #6656 or #10132.

In my case, the problem occurs when Claude automatically triggers its internal Bash tool in a Linux environment — not when running commands manually or inside VSCode.

I am running into this same issue on macos v2.0.28

I have the exact same problem on a Windows 11 PowerShell setup. Commands will stay in Running... state for multiple minutes before being executed.

Same here, whenever Claude decides to run a Bash command, it will be in "Running..." state for several minutes before asking me whether it is allowed to execute it / or execute it after I approved.

Same here, whenever Claude decides to run a Bash command, it will be in "Running..." state for several minutes before asking me whether it is allowed to execute it / or execute it after I approved.

This is exactly what I'm seeing on MacOS (v2.0.51)

Same here on Windows (v2.0.55)
This makes Git Bash and re-run OS extremely slow.

Same here with 2.0.32 on MacOS.
Very frustrating to wait about 1 minute each time a bash command must be launched.

Same issue on Linux. It seems to have taken a long time waiting for permission approval

<img width="2252" height="366" alt="Image" src="https://github.com/user-attachments/assets/a283f81f-049c-47e8-9e07-ff2349b13ea9" />

I experienced the same issue and solved it by not starting fish within my zsh profile

I experienced the same issue and solved it by not starting fish within my zsh profile

@LetsGoBonkers

Can you provide more details on the specific environment or configuration where you observe this slowdown? Additionally, are you currently using the fish shell, or is it set up in your shell profile? Understanding these details might help in diagnosing the issue more effectively.

> I experienced the same issue and solved it by not starting fish within my zsh profile > @LetsGoBonkers Can you provide more details on the specific environment or configuration where you observe this slowdown? Additionally, are you currently using the fish shell, or is it set up in your shell profile? Understanding these details might help in diagnosing the issue more effectively.

sure, i was running it using the fish command in my .zprofile file on macOS 26.2. I did not try using fish as my default shell. starship is still enabled in my shell profile. other than that, my configuration is pretty much the default.

This might be caused by the same error in #17040

@LetsGoBonkers Try to use debug mode and see if there's any error that causes the retry till timeout

same here, after upgrading oh-my-zsh for zshrc on my Macbook Pro M4, no matter in iTerm2 or VScode terminal, the first serveral Bash runs smoothly, the later take years util timout and I approve each of them, and start another loop of slow running Bash commands, really cannot rely on these.

same issue for me on WSL zsh shell

Exactly the same issue here. Macbook Pro M2, iTerm2.
Claude was installed through npm install -g @anthropic-ai/claude-code.
Also tried to install via curl -fsSL https://claude.ai/install.sh | bash after uninstalling the first one, same issue.
Seems to be related to Bedrock.

EDIT: the fix that worked for me:

export ANTHROPIC_SMALL_FAST_MODEL=us.anthropic.claude-haiku-4-5-20251015-v1:0

I might be hitting the same thing in #19247 ; going to test the export ANTHROPIC_SMALL_FAST_MODEL=us.anthropic.claude-haiku-4-5-20251015-v1:0 fix next time I see it.

Confirming that export ANTHROPIC_SMALL_FAST_MODEL=us.anthropic.claude-haiku-4-5-20251015-v1:0 doesn't fix it for me.

With that set:

  Bash(mkdir -p ~/code/prompt-engineer/researcher)
  ⎿  Running… (1m 6s)
     ctrl+b to run in background

Also, frequency seems to be increasing (MacOS 15.4.1). Just got two instances of this in a row:

⏺ Bash(git add researcher/ && git commit -m "Add researcher agent with CLAUDE.md and improvement todos" && gp)
  ⎿  Running… (1m 4s)

using ANTHROPIC_LOG=debug, got the following where a mkdir froze for 2m before printing debug output. It seems like the request right afterwards didn't take long at all, suggesting that the problem is after the mkdir gets fired but before the network request gets sent:

⏺ Bash(mkdir -p /Users/odyssey/code/prompt-engineer/researcher/.claude)
  ⎿  Running… (1m 59s)e],

✶ Booping… (ctrl+c to interrupt · 2m 14s · ↓ 181 tokens)

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  -- INSERT -- mkdir -p /Users/odyssey/code/prompt-eng… (running)                                                                                                                            Update available! Run: brew upgrade claude-code
[log_c202d5] sending request {
  method: "post",
  url: "https://api.anthropic.com/v1/messages?beta=true",
  options: {
    method: "post",
    path: "/v1/messages?beta=true",
    body: {
      model: "claude-opus-4-5-20251101",
      messages: [
        [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...]
      ],
      system: [
        [Object ...], [Object ...]
      ],
      tools: [
        [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...], [Object ...]
      ],
      tool_choice: undefined,
      metadata: [Object ...],
      max_tokens: 32000,
      thinking: [Object ...],
      stream: true,
    },
    timeout: 600000,
    signal: AbortSignal {
      [Symbol(events.maxEventTargetListeners)]: 50,
      [Symbol(events.maxEventTargetListenersWarned)]: false,
      aborted: false,
      reason: undefined,
      onabort: null,
      throwIfAborted: [Function: throwIfAborted],
      addEventListener: [Function: addEventListener],
      removeEventListener: [Function: removeEventListener],
      dispatchEvent: [Function: dispatchEvent],
    },
    stream: true,
  },
  headers: {
    accept: "application/json",
    "anthropic-beta": "claude-code-20250219,oauth-2025-04-20,interleaved-thinking-2025-05-14",
    "anthropic-dangerous-direct-browser-access": "true",
    "anthropic-version": "2023-06-01",
    authorization: "***",
    "content-type": "application/json",
    "user-agent": "claude-cli/2.1.12 (external, cli)",
    "x-app": "cli",
    "x-stainless-arch": "arm64",
⏺   "x-stainless-lang": "js",
    "x-stain in the background (↓ to manage)
    "x-stainless-package-version": "0.70.0",
· Booping…inless-retry-count": "0",   6    ↑
    "x-stainless-runtime": "node",
    "x-stainless-runtime-version": "v24.3.0",
    "x-stainless-timeout": "600",
  },
}
[log_c202d5, request-id: "req_011CXM93K9KyQVJg15RbHtDj"] post https://api.anthropic.com/v1/messages?beta=true succeeded with status 200 in 1901ms

@ant-kurt would love your help here, since it looks similar to #4049 but doesn't respond to the ANTHROPIC_SMALL_FAST_MODEL fix.

Thought it might have something to do with having Bash(mkdir *) allowed in my global settings.json, but confirmed that's not it by removing it.

Right now mkdir, ls, and git commands consistently take 2m to run.. very frustrating.

EDIT: Seems that while stuck like this, pressing Ctrl-C doesn't actually kill the hung task.

I had the same issue and Claude helped me to diagnosed it. Here is the solution:

Root Cause:
Claude Code's Bash tool makes a pre-flight check using Haiku (or ANTHROPIC_SMALL_FAST_MODEL) before executing
commands. If your API key doesn't have access to this model, the request fails with 403 and retries until timeout
(~2-3 minutes), then finally runs the command.

Solution:
Add the small/fast model to your API key permissions:

• For standard Anthropic API: Ensure access to claude-haiku-4-5
• For custom/internal APIs: Enable claude-haiku-4-5 or set ANTHROPIC_SMALL_FAST_MODEL to an accessible model

For custom API endpoints (like internal enterprise deployments):
Add to ~/.claude/settings.json:
{
"env": {
"ANTHROPIC_SMALL_FAST_MODEL": "claude-sonnet-4-5"
}
}

Then restart Claude Code.

Verification:
Run ANTHROPIC_LOG=debug claude and check for 403 errors when Bash commands are triggered.

Confirming that @lionhylra 's fix doesn't resolve the issue for me:

1. I don't see any 403s in the debug log
2. Setting export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5-20251001 doesn't change anything
3. The debug logs are just filled with the following while the Bash command (an ls, in this case) is stuck:

2026-01-24T16:56:10.692Z [DEBUG] High write ratio: blit=370, write=1351 (78.5% writes), screen=35x185
2026-01-24T16:56:11.710Z [DEBUG] High write ratio: blit=370, write=1351 (78.5% writes), screen=35x185
2026-01-24T16:56:12.720Z [DEBUG] High write ratio: blit=370, write=1351 (78.5% writes), screen=35x185
2026-01-24T16:56:13.726Z [DEBUG] High write ratio: blit=370, write=1351 (78.5% writes), screen=35x185
2026-01-24T16:56:14.699Z [DEBUG] High write ratio: blit=370, write=1351 (78.5% writes), screen=35x185
2026-01-24T16:56:15.733Z [DEBUG] High write ratio: blit=370, write=1351 (78.5% writes), screen=35x185
2026-01-24T16:56:16.737Z [DEBUG] High write ratio: blit=370, write=1351 (78.5% writes), screen=35x185
2026-01-24T16:56:17.701Z [DEBUG] High write ratio: blit=370, write=1351 (78.5% writes), screen=35x185
2026-01-24T16:56:18.737Z [DEBUG] High write ratio: blit=370, write=1352 (78.5% writes), screen=35x185
 

Possible thread to pull on: in my logs I see the following around shell snapshot code:

2026-01-24T16:55:58.681Z [DEBUG] Shell binary exists: true
2026-01-24T16:55:58.681Z [DEBUG] Execution timeout: 10000ms
2026-01-24T16:55:58.694Z [DEBUG] High write ratio: blit=370, write=1300 (77.8% writes), screen=29x185
2026-01-24T16:56:08.683Z [DEBUG] Shell snapshot creation failed:
.... bunch of Bash....
2026-01-24T16:56:08.683Z [DEBUG] Error details:
2026-01-24T16:56:08.683Z [DEBUG] - Error code: null
2026-01-24T16:56:08.683Z [DEBUG] - Error signal: SIGTERM
2026-01-24T16:56:08.684Z [DEBUG] - Error killed: true

so at least 10 of the seconds are due to the same bug as https://github.com/anthropics/claude-code/issues/19585

I found a fix.

The problem is that Claude's shell snapshotting tool somehow ends up reading the .bashrc. Apparently, it didn't like mine.

I added this at the start of my .bashrc, and now Bash commands are working instantly again:

# Skip all this init for non-interactive shells, as Claude was
# choking on it
if [[ "${-}" != *i* ]]; then
    return
fi

So if you run claude --debug and see Shell snapshot creation failed in the logs, then try adding this.

Also relevant: https://github.com/anthropics/claude-code/issues/3505

I'm using a corporate llmproxy. That implies adding the prefix "vertex_ai" for all the models including the SMALL_FAST one I didn't customize.

Adding this to my settings.json solved my problem:
"ANTHROPIC_SMALL_FAST_MODEL": "vertex_ai/claude-haiku-4-5"


No more frustrations when calling bash tool :-)

## I found a fix. The problem is that Claude's shell snapshotting tool somehow ends up reading the .bashrc. Apparently, it didn't like mine. I added this at the start of my .bashrc, and now Bash commands are working instantly again: `` # Skip all this init for non-interactive shells, as Claude was # choking on it if [[ "${-}" != *i* ]]; then return fi ` So if you run claude --debug and see Shell snapshot creation failed` in the logs, then try adding this.

You are GOATED. I have been trying to fix this for so long. Stayed up until 4:30AM just now trying so many different solutions. You finally saved me. Owe you a trillion dollars

Haha thanks @edwarddjss ; glad it helped!

> ## I found a fix. > The problem is that Claude's shell snapshotting tool somehow ends up reading the .bashrc. Apparently, it didn't like mine. > I added this at the start of my .bashrc, and now Bash commands are working instantly again: > `` > # Skip all this init for non-interactive shells, as Claude was > # choking on it > if [[ "${-}" != *i* ]]; then > return > fi > ` > > > > > > > > > > > > So if you run claude --debug and see Shell snapshot creation failed` in the logs, then try adding this. You are GOATED. I have been trying to fix this for so long. Stayed up until 4:30AM just now trying so many different solutions. You finally saved me. Owe you a trillion dollars

Thank you but I still got the very slow response from Bash in Claude CLI

<img width="267" height="95" alt="Image" src="https://github.com/user-attachments/assets/9beed8f0-4dca-4e38-9c05-557b491a1aa8" />

I think 3m is a very slow response

Same here on linux. This makes it impossible to use claude code.

For anyone who uses claude code with bedrock models, check if your IAM role has this policy AWSMarketplaceManageSubscriptions , the error I got for the slowness is

403 Model access is denied due to IAM user or service role is not authorized to perform the required AWS Marketplace actions (aws-marketplace:ViewSubscriptions, aws-marketplace:Subscribe) to enable access to this model. Refer to the Amazon Bedrock documentation for further details. Your AWS Marketplace subscription for this model cannot be completed at this time. If you recently fixed this issue, try again after 2 minutes.

Unfortunately none of these fixed the issue and it's the same for me, many minutes waiting.

I also had the same situation, Windows 11, waiting a long time for a popup to see if it was allowed to run

I found Claude scans the pwd before each tool call. This can be painless if you have a small project beneath you, but painful when you've got multiple /**/node_modules and multiple work trees.

As a workaround, I'm creating an empty claude/ in my workspace, symlinking CLAUDE.md, and launching the TUI from there.

Had a similar issue related to the Bash() too, could be the same one, but I fixed it by writing an mcp that just proxies bash calls through node and have it run commands through that instead. Seems be a lot faster than waiting several minutes for anything to happen