[BUG] Bash tool returns exit 1 with no output for all commands on Windows/MINGW (set -o onecmd injection)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/19057
2. https://github.com/anthropics/claude-code/issues/26462
3. https://github.com/anthropics/claude-code/issues/26413

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

Updated diagnosis: stdout capture failure, not just onecmd

Environment: Windows 11, MINGW64, Claude Code v2.1.45 (native installer)

After deeper testing, the original characterization ("all commands fail") is inaccurate. The actual bug is more nuanced:

What actually happens

Builtins with stdout → FAIL (exit 1, no output):

• echo hello — exit 1, no output
• pwd — exit 1, no output
• printf "hello" — exit 1, no output
• type echo — exit 1, no output

Builtins with redirected/no stdout → WORK:

• echo hello > /dev/null — exit 0
• echo hello > file.txt — exit 0, file contains "hello"
• pwd > /dev/null — exit 0
• true — exit 0

External commands → WORK:

• git --version — exit 0, output shown
• node -e "console.log('hi')" — exit 0, output shown
• pnpm --version — exit 0, output shown

Mixed chains:

• echo hello; git --version — exit 0, but only git output shown (echo's output silently dropped)

Key findings

1. Builtins execute correctly — echo hello > file.txt writes "hello" to the file. The command itself is fine.
2. Claude Code's stdout capture drops builtin output — output written directly to the shell's stdout fd is lost. Output from child processes (external commands) is captured via pipes and

works.

1. Exit code 1 is artificial — it's reported when a builtin is the last/only command. If an external command follows, its exit code is used instead.
2. Snapshot patching doesn't persist — we patched set -o onecmd to set +o onecmd in all snapshot files under ~/.claude/shell-snapshots/, but each new session creates a FRESH snapshot with

onecmd re-injected. Old snapshots are not reused.

Snapshot behavior

~/.claude/shell-snapshots/ contains per-session snapshots. New sessions always create a new file rather than reusing existing ones. The snapshot capture logic erroneously includes set -o
onecmd in every captured state.

Possible regression in v2.1.45

This was working on v2.1.44 (published Feb 16). v2.1.45 (published Feb 17) may have introduced or re-introduced the snapshot capture bug.

Practical impact

Less severe than originally reported — git, node, pnpm, and all external executables work fine. Only shell builtins (echo, printf, pwd, type) have their output dropped. Workaround: node -e
"console.log(...)" instead of echo.

Updated diagnosis + confirmed v2.1.45 regression

Environment: Windows 11, MINGW64, Claude Code v2.1.45 (native installer)

After deeper testing, the original characterization ("all commands fail") is inaccurate:

What actually happens

Builtins with stdout -- FAIL (exit 1, no output):

• echo hello -- exit 1, no output
• pwd -- exit 1, no output
• printf "hello" -- exit 1, no output

Builtins with redirected/no stdout -- WORK:

• echo hello > /dev/null -- exit 0
• echo hello > file.txt -- exit 0, file contains "hello"
• true -- exit 0

External commands -- WORK:

• git --version -- exit 0, output shown
• node -e "console.log('hi')" -- exit 0, output shown
• pnpm --version -- exit 0, output shown

Mixed chains:

• echo hello; git --version -- exit 0, but only git output shown (echo output silently dropped)

Key findings

1. Builtins execute correctly -- echo hello > file.txt writes "hello" to the file. The command itself is fine.
2. Claude Code's stdout capture drops builtin output -- output written directly to the shell's stdout fd is lost. Output from child processes (external commands) is captured via pipes and

works.

1. Exit code 1 is artificial -- reported when a builtin is the last/only command. If an external command follows, its exit code is used instead.
2. Snapshot patching doesn't persist -- we patched set -o onecmd to set +o onecmd in all snapshot files under ~/.claude/shell-snapshots/, but each new session creates a FRESH snapshot with

onecmd re-injected. Old snapshots are not reused.

Confirmed regression: v2.1.45

• v2.1.44 (published Feb 16): echo hello works correctly, output captured
• v2.1.45 (published Feb 17): echo hello fails, exit 1, no output

Downgrading to v2.1.44 via npm install -g @anthropic-ai/claude-code@2.1.44 fully resolves the issue. The snapshot files generated by v2.1.44 do NOT contain set -o onecmd.

Workaround

Downgrade to v2.1.44 and disable auto-updates (/config -> Auto-update channel -> disabled, or DISABLE_AUTOUPDATER=1).

Related: #19057 (same root cause, but reports go back to v2.1.20 -- may be intermittent in earlier versions and consistent in v2.1.45)

Confirmed regression 2.1.44 -> 2.1.45 . Reproducible on native installer, the model complains about not receiving output from commands.

Generated the following report:

Bug Report

Summary

In version 2.1.45, all Bash tool calls silently return exit code 1 with no output on Windows with MINGW64/Git Bash. This is a regression from
2.1.44 where the same commands work correctly. The issue is not related to permissions — even with "Bash(*)" in the allow list, commands still
fail.

Environment

• Claude Code version: 2.1.45 (regression from 2.1.44)
• OS: Windows 11
• Shell: MINGW64/Git Bash

Steps to Reproduce

1. Install claude-code 2.1.45 on Windows with MINGW64/Git Bash
2. Ask Claude to run any shell command, e.g. echo "hello" or pwd

Expected Behavior

The command executes and returns output.

Actual Behavior

Exit code 1, no output, no error message — regardless of permission settings.

Confirmation that it's not a permissions issue

Setting "Bash(*)" in .claude/settings.local.json does not fix the problem

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.