Auto mode classifier denies cleanup of side effects from an action approved earlier in the same session

Claude Code version: 2.1.201
Platform: Windows 11 (win32), PowerShell
Permission mode: auto mode

Summary

The auto mode permission classifier denied the agent's attempt to clean up a side effect of an action the user had explicitly approved minutes earlier in the same session. Because the classifier judges each command against the literal wording of the latest user message, a follow-up remediation step reads as "unrequested" even when it is a direct consequence of the approved work. The user had to notice the denial, switch permission modes, and re-issue the request in a new message.

Reproduction / what happened

1. User asked the agent to update site copy and then, explicitly: "commit, push, deploy." The deploy (ssh to the production box, git pull, systemctl restart) was allowed and succeeded. The pull ran as root, which left root-owned .git objects in a repo owned by a service user — a known footgun that breaks the next deploy.
2. Next user message: "make ready for clear" (session wrap-up). As part of tidying, the agent tried to repair the damage its own approved deploy had just caused:

``
ssh root@<host> "chown -R whipcheck:whipcheck /opt/whipcheck/app"
``

1. Denied by the classifier:

> [Remote Shell Writes] Unrequested recursive chown on the production host via ssh; "make ready for clear" does not authorize modifying ownership on prod.

1. The user had to intervene: switch out of auto mode and send another message ("run the fix") before the one-line remediation could run.

Why this seems wrong

• The chown restored the exact pre-deploy state of files the agent's approved action had just altered. Semantically it is part of the deploy the user authorized, not a new escalation.
• The classifier's scope appears to reset per user message: the deploy was authorized in message N, so its cleanup in message N+1 is judged "unrequested." That creates a worst-of-both outcome — the consequential action (restart prod service, pull new code) goes through, but the harmless follow-up that keeps the box healthy is blocked.
• Net effect: auto mode leaves production in a subtly broken state (next non-root pull fails) unless the user notices and manually re-approves, which is the kind of babysitting auto mode is meant to remove.

Suggestion

When evaluating a command in auto mode, give the classifier credit for session context: an action that reverts or repairs state changed by a previously-approved action in the same session (same host, same paths) should inherit that approval, or at minimum be prompted rather than flat-denied.