[BUG] Auto mode classifier blocks explicitly authorized git push / git branch -D, with no reason given and no in-chat way to authorize

Environment: Claude Code (Opus 5.5 1M), auto permission mode, macOS, launched by a desktop orchestrator app (custom --settings config dir).

What happened

1. The agent made a local commit on main (comment-only change, independently verified: AST-identical, tests unchanged). Remote had not moved, so the push was a plain fast-forward - no force flags.
2. User explicitly told the agent in chat to push and delete two local branches. The project's own standing rules were also updated (by the user) to say "when the human says push, the agent pushes itself."
3. git fetch && git push origin main was denied by the auto mode classifier three times, each with "judged this action dangerous (it gave no explanation)".
4. Following the denial's hint ("the user can add a Bash permission rule"), the user asked the agent to add the allow rule via the built-in update-config skill -> denied as [Self-Modification].
5. The user tried !git push in the chat input; in this UI it is delivered to the model as plain text, not executed.

Net result: a routine, user-authorized fast-forward push could only be completed by the user leaving the session and opening a terminal.

Problems

• No reason is given for "dangerous" denials, so neither the user nor the agent can tell what would make the action acceptable.
• Explicit, repeated user authorization in the conversation has no effect, even for low-risk, reversible, non-force operations.
• The only documented escape hatch (add an allow rule) is itself blocked when the user asks the agent to do it, and the denial message doesn't say the user must edit the file by hand or where that file is.
• Separately, in the same project the content safeguard ([cyber]) flagged ordinary internal test-environment work (checking whether our own test deployment's login page works) and even blocked /compact, making the session unusable until /clear. Request IDs: dd0a9e9e-b38f-42b6-9f3d-6061b734a4b6, 7d3665e4-c0e6-449c-b815-935fa0e3cd36.

Requests

1. Always include a concrete reason in auto mode denials.
2. Let an explicit user confirmation in the current turn clear a denial (e.g. an "allow once" prompt instead of a hard deny), at least for non-destructive operations like fast-forward git push.
3. When suggesting "add a Bash permission rule", show the exact settings file path and rule string, or offer a one-click "allow this command" to the user.
4. Treat a plain git push (no --force*) to a branch the user just told the agent to push as low risk.