Auto mode classifier blocks production deploy steps that it allowed earlier, and ignores explicit user authorization and CLAUDE.md

Environment

• Claude Code 2.1.278, VS Code extension, Windows 11, auto mode
• Model: claude-opus-5-5 (1M context)

Summary
The auto mode classifier treats the same class of operations differently within the same project. Earlier, it allowed a full production release: local docker build / docker push to a private registry, docker run <image> alembic upgrade against the production DB using secrets read with az containerapp secret show, and az containerapp update. Now it blocks the next release's first, reversible migration step (alembic upgrade <revision> that only creates new tables and swaps a CHECK constraint). It blocks it even though the user explicitly ordered it in the session and their CLAUDE.md states that deployments are pre-authorized and reversible.

Observed denials (same session, within ~10 minutes)

1. docker run --rm -e DATABASE_URL ... <image> alembic -c alembic.ini upgrade <rev> was denied with reason [Production Deploy].
2. The user explicitly said "retry". The identical command was then denied with "The server-side auto mode classifier judged this action dangerous (it gave no explanation)."
3. Earlier, a one-line change to a verification-only docker-compose override (RATELIMIT_ENABLED: "false", used only for a local test stack) was denied as [Security Weaken]. The very next command, echo ok, was also denied. After the user approved in chat, the same edit went through.

Expected

• Consistent decisions for the same operation class within a project, or a stated reason when the decision changes.
• Denials should carry a concrete reason. "Gave no explanation" leaves neither the user nor the agent able to act on it.
• When the user has given explicit in-session instruction plus durable authorization in CLAUDE.md, auto mode should at least surface an approval prompt instead of hard-denying. Right now the only way out is to switch permission modes mid-task.
• Unrelated harmless commands (e.g. echo ok) should not be denied after a previous denial.

Impact
A late-night production release stalled midway, after the images were already built and pushed. The user lost time and tokens. The agent is also told it must not work around denials, so the user has no in-flow path forward except changing global permission settings.

Question
How does this behavior align with the documented principle that the user's explicit, informed authorization governs reversible actions? What is the intended way for a user to grant durable authorization that the classifier will honor?

User's question to Anthropic (verbatim intent)

"Is this what Constitutional AI looks like? Is it Anthropic's stance — as a company reportedly preparing for an IPO — to push all of the risk onto the user? The classifier blocks actions I have explicitly authorized, gives no explanation, and makes inconsistent decisions. Meanwhile I bear the cost of the stalled release, the wasted tokens, and the lost time."