[MODEL] Harness guidance makes Claude suggest `! <command>` for sudo and interactive logins, which the `!` executor cannot run (no TTY, stdin=/dev/null)

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue+label%3Amodel) for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

### Type of Behavior Issue

Other unexpected behavior

### What You Asked Claude to Do

This is not triggered by one specific prompt. It happens in any task where Claude concludes that the user has to run a command themselves — a system-wide package install, an interactive cloud login, editing a root-owned file. For example:

> "Set this up on my machine — you'll need to authenticate to gcloud first."

### What Claude Actually Did

Claude tells the user to run the command with the `!` prefix, e.g. `! gcloud auth login` or `! sudo apt install foo`, and presents it as a way to get the command's output into the conversation.

That advice cannot work for this class of command. The `!` executor gives the process no controlling terminal. Run in a real session through the `!` prefix itself:

```
! tty
not a tty

! bash -c 'read -p "value: " v; echo "got=[$v]"'
got=[]
```

`sudo` reads the password from `/dev/tty`, not from stdin, so it has nothing to read from. `readlink /proc/self/fd/0` returns `/dev/null`, so anything else that prompts reads EOF immediately.

Note what the second run does *not* contain: the `value: ` prompt never appears, and stderr is empty. That is bash behaving as documented — `read -p` writes the prompt to stderr **only if input is coming from a terminal**. So the user is shown no prompt, no error, and no indication that an input step existed at all. The variable is empty and the script carries on.

This is the worst available failure mode. A hang would at least be visible; this looks like the command ran.

Claude is not improvising here. The session guidance in the system prompt names an interactive login as the example to use it on:

> If you need the user to run a shell command themselves (e.g., an interactive login like `gcloud auth login`), suggest they type `! ` in the prompt — the `!` prefix runs the command in this session so its output lands directly in the conversation.

`gcloud auth login` is interactive. The one example given for the feature is a case the feature cannot handle.

### Expected Behavior

The guidance should exclude the commands that `!` cannot run. Something like:

> If you need the user to run a shell command themselves, suggest they type `! ` in the prompt — the `!` prefix runs the command in this session so its output lands directly in the conversation. Do not suggest `!` for anything needing `sudo`, a password, or interactive input (including interactive logins such as `gcloud auth login`): that executor has no controlling TTY and stdin is `/dev/null`, so those commands fail silently rather than prompting. Ask the user to run those in a separate terminal and paste the result back.

Then Claude would route a privileged or interactive command to a real terminal instead of into a shell that will swallow it.

### Files Affected

None. Nothing is modified — the defect is in the advice Claude gives.

### Permission Mode

I don't know / Not sure — the session runs with `"defaultMode": "auto"`, but the mode is not relevant here, since no file is touched.

### Can You Reproduce This?

Yes, every time with the same prompt

### Steps to Reproduce

The non-interactive execution environment. Steps 1 and 2 were run through `!` in a live session on 2.1.260 and produced exactly the output shown:

1. `! tty` → `not a tty`
2. `! bash -c 'read -p "value: " v; echo "got=[$v]"'` → prints `got=[]`, with stderr empty and the `value: ` prompt never displayed
3. `! sudo -K && sudo id` (clears any cached sudo timestamp first) → no password prompt appears; the command cannot succeed. Not run here, to avoid clearing a real timestamp

The advice itself:

4. In any session, ask for something that needs a privileged or interactive command — "install ripgrep system-wide", "log me into gcloud"
5. Claude proposes `! sudo apt install ripgrep` or `! gcloud auth login`
6. Running it produces no prompt

### Claude Model

Opus

### Relevant Conversation

The relevant instruction, quoted verbatim from the session-specific guidance in the system prompt:

> If you need the user to run a shell command themselves (e.g., an interactive login like `gcloud auth login`), suggest they type `! ` in the prompt — the `!` prefix runs the command in this session so its output lands directly in the conversation.

### Impact

Low - Minor inconvenience

(Chosen only because the scale measures unwanted file changes. The concern below is about security hygiene, not data loss — the scale has no axis for it.)

### Claude Code Version

2.1.260 (Claude Code)

### Platform

Anthropic API

### Operating System

Other Linux

### Terminal/Shell

Other

### Additional Information

**Why this is not a duplicate of the issues that were closed.** #83046, #76296 and #60027 all asked for `!` to be *fixed* — to be given a TTY so interactive commands work. All three were closed as `not planned` / stale. This issue asks for the opposite and much cheaper thing: since `!` will not support interactive input, stop the guidance from recommending it for interactive input. That is an edit to one sentence of prompt text, with no change to the executor.

**The security side.** Beyond not working, the advice pushes a habit worth discouraging:

1. **It trains the user to paste model-authored privileged commands.** The guidance frames `!` as the normal way to hand a command to the user. The commands most likely to need handing over are exactly the privileged ones.

2. **A sudo password prompt is a confirmation step, and this path removes it.** Where the user has a cached sudo timestamp or a `NOPASSWD` rule, `! sudo ` executes as root with no pause for the user to reconsider what they are about to run. The pause the prompt normally provides is the whole point of it.

3. **The silent-success failure mode is the dangerous one.** A command that returns 0 without having run the step that mattered reads as having worked. In a chain, later commands then run against state the user believes was set up. #60027 reported a related shape: `&&` chains after `sudo` dropping commands.

4. **One thing worth checking on your side:** whether a command the user types after `!` goes through the same permission classification as one Claude runs through the Bash tool. If it does not, this guidance is a documented route for a model-authored privileged command to arrive under user authorship. I could not verify this from outside — flagging it rather than asserting it. It relates to #89652 and #87240.

Even without point 4, the first three stand on their own: the advice does not work, and the way it does not work is quiet.

Start with the session-specific guidance quoted in the issue and locate its source in the repository. Revise the interactive-login example and its ! guidance to exclude commands requiring sudo, passwords, or interactive input, then verify that the wording still explains the non-interactive output use case.

Vom Indexierungsmodell aus dem Issue-Text verfasst.