[BUG] Bash commands always timeout after 2 minutes despite successful completion

I second this - also been getting this issue - the bash command succeeds right away (I can see a new file created for example) but then proceeds to wait 2 min until timeout before moving on

Using sudo claude "fixes" the issue, but will cause other permission issues. Reference:

> note that sudo claude seems to help with this, at the cost of messing up other operations (commits get created as root for one, and then ssh-agent . I'm also using mise for node+npm, but it persisted when using fnm as well. persists when I do sudo -u $USER claude. thanks, can confirm this allows claude to run commands (but introduces other problems caused by sudo usage)

Another workaround which doesn't need sudo usage: installing claude using homebrew.

i also have this issue and installed using brew so that's not the solution.

May be you can try different $SHELL.
For me, I use this cmd to run claude and it works.

 SHELL=/usr/bin/zsh claude

yes, this worked for me. thanks.

I'm having exactly the same symptoms. Every shell command executed 'successfully' runs but claude takes the full 2 minute default timeout to notice and react.

Executing via SHELL=/bin/bash claude or SHELL=/bin/zsh claude works for me as well.

My default login shell is bash 5.3.3 installed via homebrew at /opt/homebrew/bin/bash.

This is a symlink.

$ ls -lA $SHELL                                                                                                                         │
lrwxr-xr-x 1 tim.visher admin 29 Sep  4 15:48 /opt/homebrew/bin/bash -> ../Cellar/bash/5.3.3/bin/bash*

I installed claude via the official instructions AFAICT with the small caveat that I have a wrapper that adds the keg only node@18 brew path:

$ claude --version
1.0.128 (Claude Code)

$ type claude
claude is hashed (/Users/tim.visher/.config/timvisher/ide/bash/bin/claude)

$ nl "$(type -p claude)"
     1  #!/usr/bin/env bash

     2  p=$(brew --prefix)

     3  export PATH="${p}/opt/node@18/bin:$PATH"

     4  exec "${p}/bin/claude" "$@"

---

It feels like there's zero chance that this is the issue for anyone else but what I noticed is that claude executes my shell in a context that executes my .bashrc.

My .bashrc has a coproc that it starts which does some things.

Making it so that that coproc only starts when stdout is a tty ([[ -t 0 ]]) makes it so that the shell exit is noticed immediately. Presumably this is because claude is waiting for the whole process tree to exit for some reason.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This issue is still occurring, can't believe it's not fixed yet

The buck occurs for me as well, but only when the sandbox is enabled. What's really strange is that it also occurs when I enable the sandbox and I exclude dotnet from the sandbox via excludedCommands.

This bug is still present for me on version 2.0.73 and on MacOS 14.8.3

May be you can try different $SHELL. For me, I use this cmd to run claude and it works. SHELL=/usr/bin/zsh claude

This actually works for me

UPDATE: Root cause identified - background processes in shell config

I've identified the root cause of this issue in my setup.

The Problem

I had this line in my .bash_profile:

eval $(ssh-agent)

This spawns a background ssh-agent process on every shell invocation. When Claude Code runs a bash command:

1. The command completes immediately and produces correct output
2. The bash shell exits
3. But ssh-agent remains running as a background process
4. Claude Code waits for all child processes to terminate
5. ssh-agent never terminates → 2 minute timeout

The Fix

Replaced the unconditional ssh-agent invocation with:

# Only start ssh-agent if not already running and in interactive shell
if [ -z "$SSH_AUTH_SOCK" ] && [ -n "$PS1" ]; then
    eval "$(ssh-agent -s)" > /dev/null
fi

This prevents ssh-agent from spawning in non-interactive shells.

Result

After this change, bash commands in Claude Code complete immediately without timeout.

Why the SHELL=/usr/bin/zsh workaround worked

Launching with SHELL=/usr/bin/zsh claude bypassed my bash profile entirely, avoiding the ssh-agent spawn.

Environment

• Claude Code version: 2.0.73 (native install)
• macOS: 14.8.3
• Shell: bash

This may help others diagnose similar issues related to background processes in shell configurations.

I was still facing issues with some CLI tools, e.g. dotnet build was waiting for bash timeouts.

The shell workaround didn't work for me. I narrowed my issue down to .profile and .zlogin (impacting both, bash & ZSH shells) having this RVM setup:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"

Moving this from .profile/.zprofile/.zlogin to .zshrc fixed the issue for me.

---

This change does break the RVM shell function within Claude Code. You can instruct Claude Code to use one of these workarounds for RVM:

• Option 1: Unset the function first, then source it inline. This bypasses Claude Code's shell snapshot which doesn't play well with RVM's shell function mechanism.

``shell
unset -f rvm && source "$HOME/.rvm/scripts/rvm" && rvm --version
``

• Option 2: Use the binary directly

``shell
~/.rvm/bin/rvm --version
``

Spent a while debugging this, and finally found the culprit in my case — a chpwd() hook in my .zshrc that runs eza after every cd (auto-ls). Claude Code snapshots your shell environment at startup, including functions. So every command that involves a cd triggered eza as a child process, and since CC waits for all child FDs to close, every single command hangs — not just builds, even git status.

Removing the chpwd hook fixed everything completely. No wrappers needed.

This would affect anyone with an auto-ls-on-cd setup in their shell (pretty common in dotfiles). More generally, avoid shell hooks (chpwd, precmd, preexec) that spawn external processes — CC snapshots and replays them in its non-interactive shell.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

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.