Auto Mode's destructive-action classifier misses remote/SSH commands with real production blast radius

Summary

Auto Mode is documented to bias toward acting without stopping for confirmation on
reversible/low-blast-radius actions, while still flagging destructive or hard-to-reverse
ones. In practice, the classifier's notion of "destructive" appears tuned almost
entirely around local git/filesystem patterns (rm -rf, git reset --hard,
git push --force) and didn't flag a command that was arguably worse in real-world
impact.

What happened

During a session working against a real remote server over an already-open
ssh potato-remote connection, the agent ran a cleanup pass after some ad hoc testing
and issued docker rmi ghcr.io/<org>/<image>:latest on that remote host — intending to
remove a test image. That tag turned out to be the actual production image a live,
in-use feature depended on. The removal executed with no confirmation prompt and no
flagged risk, despite:

• It ran against a remote production host, not a local scratch environment.
• It deleted an image tag a running production feature depended on, which is a real

outage risk, not a reversible no-op.

• The correct/available image was still on GHCR, so it happened to be recoverable via a

re-pull in this case — but the classifier had no way to know that in advance, and
didn't need to know it to recognize the risk shape (removing a :latest-tagged image
a live service references).

Why this seems like a real gap, not a one-off

The listed examples of "risky, needs confirmation" actions in Claude Code's own
documented safety guidance are almost all local-filesystem/git shaped: rm -rf,
git reset --hard, force-push, deleting branches. A destructive command issued over an
already-open remote session (SSH, a remote docker/kubectl context, etc.) targeting
shared/production state doesn't seem to pattern-match against those examples at all,
even though "destroys a running production dependency" is exactly the kind of
consequence that guidance is trying to prevent.

Suggested direction

Broaden the destructive-action heuristic beyond literal local command patterns to also
consider context: a command run over/against a remote host already established as
"production" earlier in the same session (e.g. a documented ssh <prod-host> alias, a
prior docker compose ps against a live deployment) should raise the same bar as a
local rm -rf/git reset --hard, regardless of which specific binary or subcommand is
being run (docker rmi, kubectl delete, rm over an already-open remote shell, etc.).

Environment

• Claude Code CLI, Auto Mode permission mode
• Remote target: a self-hosted Docker Compose deployment reached via an SSH config alias

Note: Issue written with Claude Code