[BUG] Auto-mode ignores permissions.ask

I was very surprised and dismayed by this behaviour.

Additional repro: git push bypasses explicit ask rule in auto mode

Settings:

{
  "permissions": {
    "ask": ["Bash(git push*)"]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git push*)",
        "hooks": [{ "type": "command", "command": "git remote -v && git branch --show-current", "timeout": 10 }]
      }
    ]
  }
}

What happened:

1. Auto mode active, user said "push to remote"
2. First attempt: blocked by a separate rule (default branch protection) — so the ask rule CAN be enforced
3. Second attempt with dangerouslyDisableSandbox: true: auto mode classifier allowed it without showing the yes/no confirmation dialog
4. Output showed: "Allowed by auto mode classifier"
5. The PreToolUse hook DID fire (showed remote info), but the ask permission rule was bypassed

Expected: The ask rule should still show the confirmation dialog in auto mode. The hook fired correctly — only the ask permission was ignored.

Workaround: Behavioral — the model must explicitly ask "About to push, confirm?" in text before running the command. This is fragile since it depends on the model remembering to do it.

Version: Claude Code latest (Opus 4.6), macOS, 2026-04-13

Still reproduces on 2026-04-17 (Opus 4.7, 1M context)

Verified the bug persists on the latest Opus release. The model version bump (4.6 → 4.7) did not fix it.

Same setup, same result:

• permissions.ask on Bash(git push*) ✓ configured
• PreToolUse hook on Bash(git push*) ✓ fires (confirmed via additionalContext injection showing branch + upstream)
• Auto mode classifier silently allowed git push --dry-run origin HEAD:test-branch without rendering the approval dialog

Additional testing — classifier interprets autoMode.environment text unpredictably:

Tried several phrasings to coax a dialog:

| autoMode.environment text | Classifier result |
|---|---|
| (nothing about pushes) | Silent allow |
| "ALWAYS defer to permissions.ask dialog, do NOT auto-execute" | Hard deny with reason "must defer to permissions.ask" |
| "ALLOW all variants through to the permissions layer" | Silent allow |

None produced a dialog. The classifier's output space appears limited to allow/deny — it can't route to "ask" even when permissions.ask is explicitly configured.

Per Anthropic docs, this is by design:

Auto mode lets Claude execute without permission prompts. A separate classifier model reviews actions before they run.

— permission-modes.md

So permissions.ask is effectively a no-op in auto mode. The docs and the behavior agree, but this contradicts user expectation when both ask and autoMode are configured together — either the user means "ask even in auto" or the config surface should make the conflict visible.

Current workaround (adding here for future readers):

Put the gate in autoMode.soft_deny — the classifier respects it and denies with a helpful prompt telling the user to toggle auto mode off:

"autoMode": {
  "soft_deny": [
    "git push (any variant): deny in auto mode with reason 'git push requires manual approval — toggle auto mode off (Shift+Tab) and retry; the approval dialog fires in default mode'."
  ]
}

Works, but it's a double-negative: auto mode denies so default mode can prompt.

Suggested fix: either (a) let permissions.ask render its dialog in auto mode with a single yes/no gate, or (b) add autoMode.ask as a first-class option so the classifier can explicitly route to dialog instead of being forced into binary allow/deny.

Workaround: a PreToolUse hook that emits permissionDecision: "ask" still prompts in auto mode. The bypass affects only the static permissions.ask list; hook-emitted decisions are honored.

Example: https://github.com/chrisguillory/claude-workspace/blob/45469aa/hooks/ask-before-auto-approval.py

If this is indeed by design, the design needs a re-think, especially since auto-mode has become the default. Auto mode is nice in that it bypasses a lot of unnecessary permissions prompts. I don't need to see a prompt every time Claude Code writes a script to perform some task and that script happens to contain a comment and a backslash. That's where it's useful. But if any ask permissions are configured, it should be obvious that bypassing the permissions prompt for such items is always the wrong thing to do.

Personally, I review every commit and some adds. So, I've gone to great trouble to set ask permission on git commit and git add. I say great trouble, because in order for my permissions to be honored, I've had to explicitly deny git -C, git --work-tree, etc. due to limitations in the permissions system. This also means that I have to steer Claude Code from time to time when it tries to run git -C, gets denied, and assumes that it isn't allowed to use git. This is why I say I've gone to great trouble to ensure that I get asked about all commits, and I'm not happy about my effort being thrown away.

For the last 2–3 days, auto mode seems to have started to work the way everyone in this thread has asked for it to work. E.g. since I have git push in permissions.ask, now I'm prompted every time, including in auto mode.

IMHO this is a pretty big step back! If I say "it's OK to git push to a feature branch", I _want_ the auto classifier to approve those specific tool usages.

On the other hand, I would always want to be asked about a git push --force, so I completely understand the point raised by this issue.

My only apparent workaround right now is to remove git push from permissions.ask, which reduces the safety of every session.

Maybe what's needed is a distinction between a "soft ask" that can be approved by the auto-mode classifier, and a "hard ask" that can only be approved by the user.

@aaronadamsCA: It seems like the new way is to use the new auto-mode soft-deny feature. This seems to pop up a permissions prompt for me--presumably because I also have ask configured.

I hit this as well; very surprising that what I have explicitly configured in ask gets auto-approved (e.g. brew install should always ask; I don't want the auto mode making any decisions on this)

The bug seems to be fixed. I noticed that in v2.1.143 of claude code auto-mode is correctly honoring rules defined in persmissions.ask and it correctly prompt for explicit permission.

Still reproduces on v2.1.175 (model: claude-fable-5, Linux/WSL2), so this either regressed after the fix mentioned above or was never fully fixed.

In auto mode, with this in ~/.claude/settings.json:

```json
"ask": ["Bash(git push --force-with-lease*)"]

  Claude ran the following without any prompt:

git add <file> && git commit -m "<msg>" 2>&1 | tail -3 && git push --force-with-lease origin <branch> 2>&1 | tail -3

  The force-with-lease push went through silently. 

Note: the remote host was in `sandbox.network.allowedDomains`, so the command ran fully sandboxed - if the fix only covered the classifier path, the sandbox auto-allow path may still skip ask rules. 

Still reproduces on v2.1.181 (Claude Opus 4.7 via Amazon Bedrock, macOS) - and unline @terence-microej's report above this is not a sandbox-network path, it's the plain Bash tool with no sandbox.network.allowedDomains involved.

Setup in ~/.claude/settings.json:

{  [...]
  "permissions": {
    "allow": ["Bash(git *)", ...],
    "ask": ["Bash(git commit *)", "Bash(git push *)", "Bash(git push --force *)", "Bash(git push -f *)", ...]
  }
}

Session started in default, switched to auto mid-task after a plan-mode approval. Later in the same session Claude ran, with no prompt at all:

git -C /abs/path commit -m "..."
git -C /abs/path push -u origin <feature-branch>

Both calls match an explicit ask rule, both should have prompted per permission-modes docs (https://code.claude.com/docs/en/permission-modes.md) ("Explicit ask rules still force a prompt"), neither did. The session JSONL contains the tool_use + tool_result for each call with no permissionDecision entry in between - they were silently approved.

The Bash(git *) allow rule appears to be winning over the more specific ask rules in auto mode, which contradicts the documented "deny -> ask -> allow" precedence. It does not repro in default mode with the same settings - the same git commit/git push calls prompt as expected.

Workaround used: a PreToolUse hook emitting permissionDecision: "ask" (as @GC-Scott earlier comment) - still works on 2.1.181.

Hi Redysz,

What you're describing is actually different. When Claude ran "git -C ..." it matched your allow rule, not your ask rule because the rule matches on text, not on intelligence. The call didn't start with "git commit" because there was a -C in the middle. If you want to avoid such issues, you'll need a deny rule on "git -C" and some guidance for Claude to help it understand that when it calls git and gets denied that git isn't the denial, it's the -C.
________________________________
From: Karol Kurek @.*>
Sent: Tuesday, June 30, 2026 5:34 AM
To: anthropics/claude-code @.*>
Cc: Severance, Scott @.>; Mention @.>
Subject: [EXTERNAL] Re: [anthropics/claude-code] [BUG] Auto-mode ignores permissions.ask (Issue #42797)

[https://avatars.githubusercontent.com/u/25427869?s=20&v=4]Redysz left a comment (anthropics/claude-code#42797)<https://github.com/anthropics/claude-code/issues/42797#issuecomment-4841913716>

Still reproduces on v2.1.181 (Claude Opus 4.7 via Amazon Bedrock, macOS) - and unline @terence-microej<https://github.com/terence-microej>'s report above this is not a sandbox-network path, it's the plain Bash tool with no sandbox.network.allowedDomains involved.

Setup in ~/.claude/settings.json:

{ [...]
"permissions": {
"allow": ["Bash(git *)", ...],
"ask": ["Bash(git commit )", "Bash(git push )", "Bash(git push --force )", "Bash(git push -f )", ...]
}
}

Session started in default, switched to auto mid-task after a plan-mode approval. Later in the same session Claude ran, with no prompt at all:

git -C /abs/path commit -m "..."
git -C /abs/path push -u origin <feature-branch>

Both calls match an explicit ask rule, both should have prompted per permission-modes docs (https://code.claude.com/docs/en/permission-modes.md) ("Explicit ask rules still force a prompt"), neither did. The session JSONL contains the tool_use + tool_result for each call with no permissionDecision entry in between - they were silently approved.

The Bash(git *) allow rule appears to be winning over the more specific ask rules in auto mode, which contradicts the documented "deny -> ask -> allow" precedence. It does not repro in default mode with the same settings - the same git commit/git push calls prompt as expected.

Workaround used: a PreToolUse hook emitting permissionDecision: "ask" (as @GC-Scott<https://github.com/GC-Scott> earlier comment) - still works on 2.1.181.

—
Reply to this email directly, view it on GitHub<https://github.com/anthropics/claude-code/issues/42797?email_source=notifications&email_token=BGKRJB4OW46AQXSZZQWVZJD5COCUBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUGE4TCMZXGE3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4841913716>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGKRJB7IG3HOY3RE6376X635COCUBAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIMJZG4YDIMZYGUYKC5QC>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/BGKRJBYIE3RJEKJZ4NZOHQL5COCUBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUGE4TCMZXGE3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/BGKRJB5EBEQ6WK5Z2LOQ6WT5COCUBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUGE4TCMZXGE3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today!
You are receiving this because you were mentioned.Message ID: @.***>

I have been investigating this on v2.1.214 (macOS, defaultMode: "auto").

permissions.ask seems to be partially respected in auto mode.** An ask rule can fire; when it does, the prompt shows: Ask rule Bash(git push:*) overrides auto mode for this command.

However, other times the command is simply approved. If I explicitly authorize the agent to run the command with something like, "implement the plan, commit, then push", it is likely to auto-approve.

But when later in the same session it may auto-approve pushes, even if I've told it I don't want that.

I don't think it is just caching based on an exact string match. I explicitly tested with some commands that had never been approved before (such as adding --verbose) and some of those were approved. But other times (such as adding --dry-run) they prompted me.

I also tried closing and resuming the session. But the behavior was similarly inconsistent after doing that.

I think the current state is the worst of both worlds:

• Documentation says that in auto-mode an ask rule will prompt, so users think they are safer than they are.
• Sometimes the users are prompted, giving them additional (false) confidence.
• Users who _want_ auto-mode to ignore permissions.ask are still bothered my prompts sometimes.