Auto mode: contextual LLM permission judge denies explicitly authorized actions and read-only verification calls #54784

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   area:permissions

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   on Apr 29, 2026
2. github-actions commented on Apr 29, 2026

   

   github-actionsBot

   on Apr 29, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. [Bug] Auto-mode classifier incorrectly blocks requested PR comment edits #52105
   2. auto-mode permission-deny envelope returned without intercepting Bash dispatch (silent-bypass on git push origin main, CLI 2.1.114, Opus 4.7) #50624
   3. Auto-mode permission decider denies remediation-gated retries after PreToolUse hook denial #51676

   This issue will be automatically closed as a duplicate in 3 days.

   • If your issue is a duplicate, please close it and 👍 the existing issue instead
   • To prevent auto-closure, add a comment or 👎 this comment

   🤖 Generated with Claude Code
3. 0xbrainkid commented on Apr 29, 2026

   

   0xbrainkid

   on Apr 29, 2026

   More actions

   This is authority-resolution failure inside the approval layer.

   If Auto mode’s contextual permission judge denies actions the user explicitly authorized — including read-only verification calls — then the system is letting an inferred safety layer override the operator’s clear intent without a reliable explanation of why.

   Why it matters:

   • explicit authorization should be the strongest signal unless a higher-priority hard policy is actually in play
   • read-only verification calls are often the safest way to confirm state before or after a change
   • when the permission judge blocks both the action and the verification path, users lose the ability to inspect, recover, or trust the boundary

   I would want clarity on:

   1. whether the denial is coming from a true hard-policy rule, model misclassification, or stale contextual state in the permission judge
   2. whether the runtime distinguishes user explicitly approved from model inferred risky intent in a way users can inspect
   3. whether read-only verification calls can be treated as a lower-risk class so users are not blocked from checking state they already have authority to inspect

   Authority boundaries need a clear ordering. If inferred contextual judgment can silently outrank explicit approval, the control surface stops being dependable.
4. Jorrinbruil commented on May 7, 2026

   

   Jorrinbruil

   on May 7, 2026

   More actions

   Adding a non-determinism angle to this — same Edit call denied, then allowed, in the same auto-mode
   session.

   Repro (Claude Code, Opus 4.7 [1M], macOS, auto mode on, defaultMode: "default"):

   1. Skill /spinner-verbs runs Edit on ~/.claude/settings.json (replacing only the spinnerVerbs.verbs
      array).
   2. First call → denied:
      ▎ Editing agent's own settings.json is Self-Modification. ... To allow this type of action in the future,
      the user can add a Bash permission rule to their settings.
   3. Bash fallback (python3 -c '...json.dump...' writing the same file) → also denied:
      ▎ Modifying ~/.claude/settings.json is self-modification of agent configuration.
   4. User asked the agent to retry the same skill with a different theme. Second call → succeeded silently,
      no prompt, no permission change in between.

   Two extra issues on top of the ones in the OP:

   • Inconsistency: identical operation (same tool, same path, same session, same auto mode) is gated
     non-deterministically. Users can't predict whether their workflow will succeed.
   • Wrong remediation hint: the deny message tells the user to "add a Bash permission rule", but the block
     also fires on the Edit tool. Bash rules don't cover Edit, so the suggested workaround doesn't apply to the
     tool that was actually denied.

   If the judge is intentionally probabilistic, that should be documented; if not, the gate state needs to be
   deterministic and inspectable.
5. github-actions

   added

   staleIssue is inactiveIssue is inactive

   on May 21, 2026
6. github-actions commented on Jun 5, 2026

   

   github-actionsBot

   on Jun 5, 2026 – with GitHub Actions

   More actions

   Closing for now — inactive for too long. Please open a new issue if this is still relevant.
7. github-actions

   closed this as not plannedon Jun 5, 2026
8. github-actions commented on Aug 8, 2026

   

   github-actionsBot

   on Aug 8, 2026 – with GitHub Actions

   More actions

   This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
9. github-actions

   locked as resolved and limited conversation to collaborators on Aug 8, 2026