[BUG] `Bash` tool executes the user's login shell (e.g. /bin/zsh) and should thus be called "shell" not "bash"; LLM trips over bash-only idioms

Summary

The Bash tool's description begins "Executes a bash command and returns its output." On macOS with SHELL=/bin/zsh, the command is actually evaluated by the zsh, not bash. The tool name and description therefore assert an interpreter that isn't the one running the command.

This isn't cosmetic: zsh and bash differ in default options that change control flow. The model writes idiomatic bash (because the tool says bash), and the divergence shows up as a failed command with an error that doesn't name the cause.

I hit this organically mid-task, not while hunting for it:

<img width="439" height="153" alt="Image" src="https://github.com/user-attachments/assets/9ecf95b4-02a4-4ff9-a339-e538a3398427" />

It's wrong to call something bash if it's actually zsh. The end user sees bash in the terminal when it's zsh. So Claude saying "I hit a zsh error" is weird when the tool name is "bash". You should call it the "Shell" tool if it's the system shell, not "bash" which is a particular type of shell.

Proof that the interpreter is zsh

$ echo "\$0 = $0"; echo "BASH_VERSION = ${BASH_VERSION:-<unset>}"; echo "ZSH_VERSION = ${ZSH_VERSION:-<unset>}"; ps -o comm= -p $$
$0 = /bin/zsh
BASH_VERSION = <unset>
ZSH_VERSION = 5.9
/bin/zsh

The (eval):1: prefix on shell errors also indicates the command is handed to the shell through eval.

Repro

One Bash tool call:

cd /some/empty/dir
rm -f nope*.txt && echo "FOLLOW-UP RAN"
echo "exit status of the chain: $?"

Actual (via the Bash tool → zsh):

(eval):1: no matches found: nope*.txt
exit status of the chain: 1

Expected (what "Executes a bash command" implies — same line, real bash):

$ /bin/bash -c 'cd /some/empty/dir; rm -f nope*.txt && echo "FOLLOW-UP RAN"; echo "exit status: $?"'
FOLLOW-UP RAN
exit status: 0

zsh's nomatch option is on by default: an unmatched glob is a shell error, so rm never runs and the shell returns nonzero. bash passes the unmatched pattern through literally; rm -f ignores a missing file and exits 0.

Why the current signals aren't sufficient

• The tool description says "bash" in the first sentence and never mentions that the shell is the user's login shell. It does say "the shell is initialized from the user's profile," which is about initialization, not about which interpreter.
• The session environment block does say Shell: zsh. So the information exists, but it directly contradicts the tool's own name and description, and the contradiction is only resolvable by running echo $0.
• The failure mode gives no hint. (eval):1: no matches found: doesn't say "this is zsh, bash would have accepted this."

Other defaults that diverge the same way and would produce silently different behavior: unquoted parameter expansion isn't word-split in zsh, arrays are 1-indexed, ** recursive globbing is on, echo flag handling differs, and set -o pipefail semantics/availability differ across versions.

Environment

• Environment Info
• Platform: darwin
• Terminal: xterm-256color
• Version: 2.1.258
• Claude Code 2.1.258
• macOS 26.6.2 (arm64)
• SHELL=/bin/zsh, zsh 5.9
• Feedback ID: b4915ce3-a6ab-4f3e-82e6-9cf58fabaafb

Related

• #7490 — feature request to configure the Bash tool's shell / inherit the initial shell. That's about choice of shell. This report is narrower: whatever shell is chosen, the tool shouldn't describe itself as bash while running something else, and a shell-level failure shouldn't be indistinguishable from a no-op.

Suggested fix

The name and the interpreter need to agree. Any of these three is coherent — the current combination (called bash, runs zsh) is the only one that isn't:

1. Actually use bash. Run the command through bash -c, keeping the login shell only for deriving profile env. The name becomes true and bash-idiomatic output from the model becomes correct. (This is roughly the #7490 direction and the biggest behavioral change.)
2. Name it after the real shell. Call the tool Zsh — or interpolate the detected shell into the name/description — so it says what it runs.
3. Name it generically. Call it Shell, with a description that states which interpreter is in use ("Executes a command in the user's login shell, currently /bin/zsh"). This is the cheapest option and keeps one stable tool name across users whose shells differ, while still removing the wrong bash prior.

Options 2 and 3 are documentation-only and would each have prevented this instance.

Independently of which is chosen: annotate the failure. When a command exits nonzero with a recognizably shell-specific error (no matches found:, not valid in this context:), append a one-line note to the tool result naming the shell and the divergence. That converts a confusing silent no-op into an actionable error.

{ "env": { "CLAUDE_CODE_SHELL": "/opt/homebrew/bin/bash" } }

cd /some/empty/dir
rm -f nope*.txt && echo "FOLLOW-UP RAN"
echo "exit status of the chain: $?"
echo "BASH_VERSION = ${BASH_VERSION:-<unset>}"; echo "SHELL = $SHELL"; ps -o comm= -p $$

FOLLOW-UP RAN
exit status of the chain: 0
BASH_VERSION = 5.3.15(1)-release
SHELL = /opt/homebrew/bin/bash
/opt/homebrew/bin/bash

// environment block "Shell:" line
let e=a.SHELL||"unknown",n=e.includes("zsh")?"zsh":e.includes("bash")?"bash":e
// Bash tool shell resolution
let e=a.CLAUDE_CODE_SHELL;if(e)if((e.includes("bash")||e.includes("zsh"))&&await obt(e))return t(`Using shell override: ${e}`),e;

pids=""; for i in 1 2 3 4 5 6 7 8; do ( while :; do :; done ) & pids="$pids $!"; done
kill $pids 2>/dev/null

zsh -c 'pids=""; for i in 1 2 3; do sleep 30 & pids="$pids $!"; done;
        set -- $pids; echo "args to kill: $#"; kill $pids 2>/dev/null; echo "rc=$?"'
# args to kill: 1
# rc=1          <- nothing killed, no visible error