Auto-mode classifier hard-denies commands explicitly allowed by user permission rules, with no path for the user to approve

Summary

In a desktop-app (Code tab) session running in auto permission mode, the auto-mode classifier denies codex exec launches with reason "[Create Unsafe Agents]" even though:

1. The project's .claude/settings.json contains an explicit user-added allow rule whose prefix the command exactly matches: Bash(codex exec --dangerously-bypass-approvals-and-sandbox*) (added deliberately weeks ago; identical launches ran fine from sessions as recently as the previous day).
2. A strictly SAFER form (codex exec --full-auto, i.e. sandboxed workspace-write, no sandbox bypass) is denied with the same reason.
3. The denial is terminal — there is no interactive escalation. The user was present, explicitly approving, and directing the action in chat, but auto mode offers no prompt to convert that approval into permission. The denial text says 'the user can add a permission rule to their settings' — the user already had.

Expected

Explicit user allow rules should take precedence over the auto-mode classifier (that is what they are for), or at minimum a classifier denial should surface as an approvable prompt to the user rather than a hard block.

Impact

A previously-working, user-authorized automation lane (delegating parsing work to a second CLI agent on the user's own machine, operating on local files) is now dead in auto mode. The practical pressure this creates is the user switching the whole session to bypassPermissions mode to get their workflow back — a net safety regression. The user asked that this be reported.

Environment

Claude Code desktop app (Code tab), Windows 11, auto permission mode, 2.1.28x era (current as of 2026-10-07).