[BUG] Bash Commands do not execute, Return No Output

Status Closed — not planned
Reported on v2.1.81
Maintainer reply None cached
Activity 15 comments · opened Apr 1, 2026 · closed Jun 29, 2026

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?

All bash commands executed through the Bash tool return (Bash completed with no output) regardless of the command. This affects even the simplest commands like echo, pwd, and ls.

What Should Happen?

Bash commands should return their standard output, for example:

  • echo "test" should return: test
  • pwd should return the current working directory path
  • ls should return directory contents

Error Messages/Logs

`(Bash completed with no output)`

Steps to Reproduce

  1. Start Claude Code session
  2. Ask Claude to run any bash command, for example:
  • echo "test"
  • pwd
  • ls
  • which bash
  1. Observe result: (Bash completed with no output)

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.81 (Claude Code) stable channel, confirmed up to date as of 2026-03-31

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Additional Observations

  • Other tools work normally:
  • Read tool ✓
  • Write tool ✓
  • Glob tool ✓
  • Grep tool ✓
  • Issue is consistent:
  • Occurs across multiple environments (Docker and native macOS)
  • Persists across sessions
  • Affects ALL bash commands without exception
  • User's terminal works normally:
  • User can run bash commands directly in terminal successfully
  • Issue is isolated to Claude Code's bash execution/capture
  • No obvious configuration issues:
  • Checked ~/.claude/settings.json - no bash-specific redirections
  • No unusual environment variables that would suppress output

Impact

  • Severity: Medium-High
  • Users cannot use Claude to run bash commands for diagnostics, system operations, or automation
  • Workaround exists: Ask user to run commands manually, but this defeats the purpose of Claude Code automation

Suggested Investigation Areas

  1. Bash stdout capture mechanism in Claude Code
  2. Pipe/buffer handling for bash subprocess output
  3. TTY/PTY allocation for bash subprocess
  4. Shell initialization or profile loading that might redirect stdout

Configuration Files

Settings from ~/.claude/settings.json:

{
  "apiKeyHelper": "/Users/djbyrne/Desktop/genAI/genai_api/claude_code_apikeyhelper.sh",
  "env": {
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1",
    "CLAUDE_CODE_API_KEY_HELPER_TTL_MS": "1800000",
    "ENABLE_TOOL_SEARCH": "0",
    "ANTHROPIC_BASE_URL": "https://gov.genai-api.jpl.nasa.gov/sub-id-djbyrne-timecard-govcloud",
    "ANTHROPIC_MODEL": "us-gov.anthropic.claude-sonnet-4-5-20250929-v1:0"
  }
}

Session Information

  • Project: /Users/dj_pastlives/2026_genAI/claude/20260331_pdf_and_plantuml
  • Session occurred: 2026-03-31

Contact

  • User: djbyrne
  • Organization: JPL (Jet Propulsion Laboratory)

---

Note: This issue was discovered and documented with assistance from Claude during an active debugging session where we attempted to diagnose the problem using non-bash tools.

View original on GitHub ↗

15 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/19663
  2. https://github.com/anthropics/claude-code/issues/41124
  3. https://github.com/anthropics/claude-code/issues/32778

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

djbyrne17 · 5 months ago

It's not just the output; bash commands are not executing at all. Snippet of session below.

⏺ Bash(pwd > /Users/dj_pastlives/2026_genAI/claude/20260331_pdf_and_plantuml/test_output.txt)
⎿  (No output)

Read 1 file (ctrl+o to expand)

⏺ No, the workaround doesn't work. The bash commands appear to complete but they're not actually
executing - the redirected output files aren't being created at all.

This is an important finding: bash commands aren't just failing to capture stdout, they're not
executing at all. The "completed with no output" message is misleading - it should probably say "no
execution" or show an error.

This makes the bug more severe than we initially thought. It's not just a stdout capture issue -
the bash subprocess isn't executing the commands at all.

djbyrne17 · 5 months ago

In addition to seeing this on macOS Tahoe 26.3.1, I have the same problem in a docker environment on linux
Linux 4.18.0-553.72.1.el8_10.x86_64 #1 SMP Sat Aug 23 20:13:38 EDT 2025 x86_64 x86_64 x86_64 GNU/Linux
but not on the same linux box outside of docker.

latannon · 4 months ago

Hi, I a m facing the same issue on Windows 11 too (with Git Bash)

itsuitsuki · 4 months ago

same issue on windows 11 too with git bash

qingshu-ui · 4 months ago

Hey, I kind of know what's going on with this.

You need to set the system variable CLAUDE_CODE_GIT_BASH_PATH

  • You need to provide D:\Programs\Git\bin\bash.exe instead of D:\Programs\Git\git-bash.exe
  • DO NOT D:\Programs\Git\git-bash.exe

Here's the final outcome:

<img width="839" height="217" alt="Image" src="https://github.com/user-attachments/assets/9f50f839-3107-4e85-b663-4cd95ffb6631" />

<img width="1195" height="716" alt="Image" src="https://github.com/user-attachments/assets/f9d8073b-5775-4542-8627-96170f5a0f67" />

djbyrne17 · 4 months ago
## You need to set the system variable CLAUDE_CODE_GIT_BASH_PATH

On the macOS or linux/docker platforms where I'm seeing the problem, CLAUDE_CODE_GIT_BASH_PATH is not relevant. I hope it helps someone else.

djbyrne17 · 4 months ago

This turned out to be a problem where ${HOME}/.profile exited. I do not understand why that matters but have an easy work-around.

djbyrne17 · 4 months ago

This issue was fixed by re-factoring ~/.profile to remove the need for an exit command. Claude should learn to verify whether login shells it spawns actually exist. It could also simply look for exit statements in .profile (or other login files such as .bashrc) when troubleshooting an inability to execute shell commands.

nflechner · 3 months ago

Same issue here. macOS, Claude Code 2.1.141, Node 22.22.3, Terminal.app.

(below CC summary of my own debugging)

Additional finding: using ps aux monitoring while Claude Code runs a bash command, I can see zsh subprocesses briefly spawn in a zombie/exiting state (zsh), then immediately disappear. So the subprocesses are being created — they just die before stdout makes it back to Claude Code.

Diagnostics I've ruled out:

  • FD exhaustion (lsof -c node returns 0)
  • TCC permission revocation (terminal works fine)
  • Shell config (clean .zshrc, no unusual env vars)
  • Node version (tested v22 and v24)
  • Citrix/NordVPN/security software interference
  • Full reinstall (rm -rf ~/.claude + fresh install)

Read, Glob, Grep, and directory listing tools all work — only Bash is affected. This was working previously; started failing and hasn't recovered.

OutOfBrain · 3 months ago

In my case it was caused by a broken shell-snapshot in ~/.claude/shell-snapshots
and a workaround in https://github.com/anthropics/claude-code/issues/1872 has helped me:

SHELL=/bin/bash claude
alias claude='SHELL=/bin/bash claude'

That is using the old system bash instead instead of homebrew bash 5.3.9 that has the issue described below.
Any other shell like zsh would also have worked:

SHELL=/bin/zsh claude

The issue with bash version 5.3.9:

line 1127 of the .claude/shell-snapshot has

eval "$(echo 'X3NlcnZpY2VzICgpIAp7IAogICAgbG9jYWwgc3lzdmRpciBmYW1kaXI7CiAgICBbIC1kIC9ldGMvcmMuZC9pbml0LmQgXSAmJiBzeXN2ZGlyPS9ldGMvcmMuZC9pbml0LmQgfHwgc3lzdmRpcj0vZXRjL2luaXQuZDsKICAgIGZhbWRpcj0vZXRjL3hpbmV0ZC5kOwogICAgQ09NUFJFUExZPSgkKHByaW50ZiAnJXNcbicgJHN5c3ZkaXIvISgqLnJwbUAob3JpZ3xuZXd8c2F2ZSl8Kn58ZnVuY3Rpb25zKSkpOwogICAgaWYgWyAtZCAkZmFtZGlyIF07IHRoZW4KICAgICAgICBDT01QUkVQTFk9KCIke0NPTVBSRVBMWVtAXX0iICQocHJpbnRmICclc1xuJyAkZmFtZGlyLyEoKi5ycG1AKG9yaWd8bmV3fHNhdmUpfCp+KSkpOwogICAgZmk7CiAgICBDT01QUkVQTFk9KCQoY29tcGdlbiAtVyAnJHtDT01QUkVQTFlbQF0jQCgkc3lzdmRpcnwkZmFtZGlyKS99JyAtLSAiJGN1ciIpKQp9Cg==' | base64 -d)" > /dev/null 2>&1

which decodes to

_services () 
{ 
    local sysvdir famdir;
    [ -d /etc/rc.d/init.d ] && sysvdir=/etc/rc.d/init.d || sysvdir=/etc/init.d;
    famdir=/etc/xinetd.d;
    COMPREPLY=($(printf '%s\n' $sysvdir/!(*.rpm@(orig|new|save)|*~|functions)));
    if [ -d $famdir ]; then
        COMPREPLY=("${COMPREPLY[@]}" $(printf '%s\n' $famdir/!(*.rpm@(orig|new|save)|*~)));
    fi;
    COMPREPLY=($(compgen -W '${COMPREPLY[@]#@($sysvdir|$famdir)/}' -- "$cur"))
}

and assumes shopt -s extglob to be set - which only happens more than a hundred lines later.
So the solution is removing that line, moving shopt -s extglob before or use another shell that doesn't have that issue / expectation.

OutOfBrain · 3 months ago

@Santiago Ruffini
So many words so little content. What did you actually find? Signal-to-noise ratio in this one is not very good.
Please use less llm and more refining. I'm unsubscribing here to not waste any more time reading empty walls of text.

santiago-ruffini · 3 months ago
@Santiago Ruffini So many words so little content. What did you actually find? Signal-to-noise ratio in this one is not very good. Please use less llm and more refining. I'm unsubscribing here to not waste any more time reading empty walls of text.

My CC session went rogue 🤪

jchesshircr · 3 months ago
github-actions[bot] · 2 months ago

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