[FEATURE] Auto mode classifier should be able to run its own read-only checks before approving, gated by a second auto-mode pass

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The auto mode classifier decides from the command text plus the conversation. When the command alone doesn't settle whether it's safe, it has no way to look. It either blocks, and I get a prompt I could have been spared, or it guesses. Some examples:

• bash ./deploy.sh or python fix.py: whether it's safe depends on what the file contains, which the classifier never reads (see #83459).
• kubectl delete pod X --context lab: whether it's safe depends on which cluster and namespace that is.
• rm -rf build/: whether it's safe depends on what build/ resolves to and whether it's tracked in git.
• git push: whether it's safe depends on the current branch and remote.

In each case, a human reviewer would run one or two read-only commands (cat, git status, kubectl get, ls -la, readlink) and then decide with confidence.

Proposed Solution

1. Classifier-initiated checks. When a verdict is uncertain, the classifier can issue its own read-only commands, see their output, then approve or deny. The results feed only the verdict. They don't enter the main agent's context.
2. A second auto-mode pass gates those checks. The classifier's own commands must not be trusted automatically, or a prompt-injected or confused classifier becomes a hole. Each check the classifier proposes goes through an independent auto-mode evaluation that is limited to read-only operations (no writes, no network mutations, bounded runtime and output). If that pass rejects a check, the classifier falls back to today's behavior: block or ask the user.
3. Visibility. The transcript shows the checks the classifier ran and their verdicts (collapsed by default), so the reasoning behind an approval can be audited.
4. Config. Opt-in or opt-out via settings. Optionally, an allowlist of commands the classifier may run for checks (e.g. git status, cat, kubectl get).

Alternative Solutions

Every workaround today is harness engineering the user has to build and maintain:

• Broad allow rules (autoMode.allow, permissions.allow). These are coarse. Bash(kubectl:*) allows delete as readily as get. Making them precise means writing and maintaining a rule set per tool, per project, per environment.
• PreToolUse hooks. These can run the same read-only checks. But each user has to write, debug and maintain their own shell logic to parse commands, decide what to inspect, and return a verdict. Every user rebuilds the same thing, and the hooks break when tools change.
• Having the main agent run the checks first. Getting it to do this reliably takes prompt and CLAUDE.md engineering. Even then, the classifier doesn't see the results as evidence it can trust, and the checks fill up the agent's context.

The feature moves this work into the classifier, where it can be done once and done well.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. The agent writes cleanup.sh and runs bash cleanup.sh.
2. The classifier can't judge it from the command text, so it proposes cat cleanup.sh.
3. The second pass confirms that cat of a file in the working directory is read-only and approves it.
4. The classifier reads the script, sees it only removes files under ./tmp/, and approves the run. No prompt reaches me.
5. If the script had held rm -rf ~ or a credential write, the classifier would have blocked it. Today that indirection hides the contents entirely.

Related: #83459, #87881