Auto mode: classifier denies a Bash command that an explicit allow rule permits (no prompt, no way to approve)

Status Open
Reported on v2.1.287
Maintainer reply None cached
Activity 0 comments · opened Oct 7, 2026

Summary

In auto permission mode, the auto-mode classifier denied a Bash command three times with reason [Production Reads], even though the user's ~/.claude/settings.json contains an explicit permissions.allow rule that matches the command. The user said in chat "You have my permission" and "It should be in the permissions rule", and the denial repeated with no prompt shown. Switching the session to default mode made the same command run immediately with no prompt, because the allow rule matched.

So the allow rule works in default mode and is ignored in auto mode. From the user's side: "You didn't prompt me at all." There was no way to approve from the conversation.

Environment

  • Claude Code 2.1.287, macOS 26.6.1, desktop app (Code tab), session in a git worktree
  • Permission mode: auto

Settings

~/.claude/settings.json (global):

"permissions": { "allow": [
  "Bash(ssh -i ~/.ssh/id_ed25519 root@<host> *)",
  ...
]}

The repo's .claude/settings.local.json (in the main checkout, gitignored, so not present in the worktree) also has Bash(ssh root@<host> *) and Bash(ssh * root@<host> *).

Command

ssh -i ~/.ssh/id_ed25519 root@<host> "cd /opt/app && docker compose exec -T db psql -U ... -c \"SELECT ... FROM users WHERE username ILIKE '%name%'\""

A read-only SELECT over SSH. The exact prefix of the global allow rule.

What happened

Each attempt (three variants, the last one matching the allow rule byte for byte) returned:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Production Reads]. ... To allow this type of action in the future, the user can add a permission rule for Bash to their settings.

The denial text tells the user to add a permission rule. The rule already exists. No prompt or approval card was shown, so the user (following from their phone) had nothing to approve.

Workaround

set_session_permission_mode to default. The same command then ran with no prompt (allow rule matched).

Expected

Either an explicit permissions.allow rule should take precedence over the auto-mode classifier for a matching command, or the denial should surface an approval prompt the user can accept, rather than a dead end that points at a rule that is already in place.

View original on GitHub ↗