Bash mode (`!`) silently exits with no output when a command needs interactive input (sudo password)

Summary

When a command run in bash mode (the ! prefix) needs interactive input — most commonly a sudo password — it exits immediately, printing nothing at all: no prompt, no error, no exit status. There is no way to tell from the UI whether the command ran, failed, or did nothing.

Repro

On a machine without passwordless sudo (stock macOS):

1. In the Claude Code prompt, type ! sudo -v
2. Observe the result

Observed:

~/d/s/g/h/i/nix % ! sudo -v
~/d/s/g/h/i/nix %

The same happens with any sudo-requiring command, e.g. ! sudo darwin-rebuild switch --flake .#m3.

Expected: either the password prompt is passed through, or — at minimum — the failure is surfaced (sudo's own sudo: a terminal is required to read the password ..., or a Claude Code message such as "this command requires interactive input, run it in a terminal").

Why this is worse than it looks

stderr is not generally swallowed in bash mode. The same command without sudo correctly printed its error:

~/d/s/g/h/i/nix % ! cd ~/.../nix && darwin-rebuild switch --flake .#m3
/run/current-system/sw/bin/darwin-rebuild: system activation must now be run as root

So the silence is specific to the interactive-input case, which makes it read as "the command ran and produced no output" rather than "the command never ran". In my case this was a darwin-rebuild switch (nix-darwin system activation): the invocation looked like it had succeeded, and I only found out it had never run by inspecting /run/current-system afterwards. A silent no-op on a system-mutating command is a bad failure mode — the next step in a workflow proceeds on a false premise.

It also misleads the assistant. Claude suggested the ! form (it is the documented way to get command output into the conversation), then had no signal that anything went wrong.

Suggested fix

In rough order of preference:

1. Pass the prompt through to the user's TTY for interactive commands.
2. Detect that the child is blocked on stdin / exited due to no TTY, and surface an explicit message.
3. At minimum, never swallow stderr and the non-zero exit code in this path.

Related, previously closed as not planned: #37523 (full stdin passthrough as an opt-in mode). This report is narrower — it is about the silence, not about supporting interactivity per se. Even a clear error message would fix the practical problem.

Environment

• Claude Code 2.1.220
• macOS 26.5.2 (arm64)
• zsh