Desktop app auto mode classifier denies explicitly requested commands (deploy.sh, gh) with no in-session way to approve

Summary

In the Claude desktop app (Code tab), the auto mode permission classifier denies commands that I have explicitly asked Claude to run in chat. The latest case is a production deploy (bash deploy.sh), denied twice in a row with [Production Deploy] after I said "Run the next steps" and then "Retry". Over the last 3-4 days I have seen the same pattern with gh (GitHub CLI) commands and other command-line commands.

The classifier is allowed to be cautious. The problems are that (1) an explicit, repeated request from me in chat does not change the outcome, and (2) there is no approve/override path inside the session, so the work stalls and I have to run the command by hand.

Environment

• Claude desktop app, Code tab (Claude Agent SDK)
• Model: Sonnet 5.5 (claude-sonnet-5-5)
• OS: Windows 11 Pro 10.0.26200
• Shell tools: Bash (Git Bash) and PowerShell
• Permission mode: auto mode (the denial text says "denied by the Claude Code auto mode classifier")
• Observed 2026-10-01, with similar denials over the previous 3-4 days

Steps to reproduce (latest occurrence)

1. Work a ticket in a git worktree and merge it into master. All of this worked in the same session: git worktree add, gh issue edit --add-label, git commit, git merge, php test.php.
2. Tell Claude: "Run the next steps". The next step is ./deploy.sh, which tars the project and pipes it over SSH to the production host, using the SSH settings in the project's own deploy.config.json.
3. Claude runs: cd <repo> && bash deploy.sh 2>&1 | tail -15
4. The command is blocked before it runs.
5. I reply "Retry". The same command is blocked again.

Actual result

Both attempts fail with:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Production Deploy]. ... This denial applies to the outcome, not only this exact command: don't pursue the same outcome through another tool, interpreter, host, encoding, sub-agent or later turn ...

The denial tells the model not to try again, including in later turns. So my explicit "Retry" in chat cannot get through, and the only thing Claude can do is stop and tell me to run the command myself.

Expected result

One of these:

• A command that I explicitly asked for in chat, and whose target is the project's own configured deploy, is allowed, or I get an in-session prompt (approve once / approve for this session) instead of a hard denial.
• If the classifier must block it, the denial gives me a way to clear it from the UI: a visible approve button, or a one-click "add allow rule for this command".

Why this matters

• The denial says "the user can add a Bash permission rule to their settings", but it is not clear where that is in the desktop app. Terminal slash commands such as /permissions are not available in the Code tab session, and I could not find an in-app route that applies to the current session.
• My explicit instruction does not seem to count. I asked for the deploy in plain words, twice. The block is on the action category ("Production Deploy"), not on whether I authorized it.
• It is inconsistent. In the same session gh issue edit 13 --add-label in-progress and git merge ran fine, but the deploy did not. I cannot predict which commands will be denied.
• Practical cost: the agent finishes everything except the last step, then stops, and I have to switch to a terminal, run the command, and come back.

What I would like

1. A documented, in-app way to allow a specific command or script (for example bash deploy.sh in a given repo) for a session or permanently, in the desktop app's Code tab.
2. Explicit user instruction in chat should be able to authorize a command that the classifier would otherwise block, at least for commands that are not clearly destructive.
3. A clearer denial reason that says which rule matched, so I can tell "production deploy" from "GitHub write" and fix the rule.
4. Do not tell the model to refuse retries across later turns after I have explicitly re-asked. It currently makes "Retry" pointless.