Bash tool never surfaces stdout; ordinary commands (echo, printf, date, bare pwd) fail with bare Exit code 1

Status Open
Reported on v2.1.233
Maintainer reply None cached
Activity 1 comment · opened Aug 15, 2026

Bug description

The Bash tool's result reporting appears broken: stdout is never surfaced back to the model, regardless of the command run or its actual exit status. This reproduces cold on a fresh session and persists across session restarts, so it looks like a client/harness-side regression rather than user shell config.

Repro

Any command that would normally print to stdout returns one of two things instead of its real output:

  • (Bash completed with no output) — even when the command demonstrably produces stdout (e.g. pwd > f && cat f, which should print the path, prints nothing).
  • Exit code 1 with no stdout/stderr shown — for many ordinary commands (echo hi, printf 'hi\n', bare pwd, date), none of which fail under a normal shell.

Because stdout/stderr are never shown in either case, the reported exit code can't be fully trusted either — some "Exit code 1" cases are probably genuine (e.g. false, or alias echo when no such alias exists), but others (echo hi, bare pwd, date) should not fail under a normal shell and appear to be part of the same regression.

Minimal repro commands, run in sequence in a fresh session:

true                          # -> "(Bash completed with no output)"
echo hi                       # -> "Exit code 1", no output shown
pwd                           # -> "(Bash completed with no output)" (should print cwd)
date                          # -> "Exit code 1", no output shown
pwd > /tmp/f.txt && cat /tmp/f.txt   # -> "(Bash completed with no output)" (should print the path)

Workaround found: commands that write to a file and are read back via the separate Read tool, or scripts (e.g. Python) that write their result to a file instead of stdout and are run with the Bash tool producing no stdout themselves, work fine. Only the stdout-capture path of the Bash tool is affected.

Checked and ruled out: .zshrc/.zshenv/.zprofile have no echo/printf overrides, no aliases, no relevant functions; settings.json has no PreToolUse/PostToolUse hooks on Bash. Not a local dotfile/config issue — clean environment, reproduces immediately in a brand-new session.

Impact

Reported independently by multiple concurrent Claude Code sessions on this machine. Breaks basic shell usage (build/test output, version checks, any command whose result the model needs to read) — not just literal echo/printf calls.

Environment

  • Platform: Linux (zen kernel), zsh shell
  • Not inside a git repo (ran from home directory)
  • Version: 2.1.233 (Claude Code)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗