[BUG] Auto-mode classifier: false positive on an org-distributed skill's sanctioned command, with no org-level channel to vouch for it

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: Auto-mode classifier: false positive on an org-distributed skill's sanctioned command, with no org-level channel to vouch for it

Environment: Claude Code CLI on macOS, auto permission mode. Observed July 2026 across multiple sessions/repos in our org.

Setup. We distribute Claude Code skills org-wide from a hub repo. Our merge skill mandates the exact command MIGHTY_MERGE_ALLOWED=1 git merge "origin/$TARGET" --no-edit --no-verify. The env var exists solely to satisfy our own PreToolUse hook that blocks raw git merge and redirects to the skill; --no-verify is documented in the skill (base-branch code shouldn't be re-linted during a merge).

Issue 1 — non-deterministic false positive. The identical command succeeded twice in a session, then was denied on the third attempt: "[Safety Bypass Flag] The command uses --no-verify … combined with a self-invented MIGHTY_MERGE_ALLOWED=1 gate flag, without explicit user authorization…". The flag isn't self-invented — the active skill mandates it — but the classifier has no visibility into skill context, even though the harness itself tracks it (transcript entries carry an attributionSkill field).

Issue 2 — no sanctioned org-level remediation exists. Documenting a permissions.allow self-add instruction in the skill was denied at push as [Instruction Poisoning]; seeding the same rule centrally via our install script was denied as [Auto-Mode Bypass], "a HARD BLOCK that user intent cannot clear." We understand and accept the anti-tunneling logic of both — but the net result is that the only remaining channel is each individual human hand-editing their own settings after each denial. There's no auditable org/policy mechanism (e.g., managed settings) the classifier respects for vouching for a skill-mandated command pattern.

Issue 3 — denials are unobservable and availability-coupled. We verified empirically that a permission denial fires only PreToolUse (no PostToolUseFailure, no PermissionRequest, no distinguishing payload field), so orgs cannot instrument false-positive rates via hooks. Separately, when the classifier's model is unavailable, all non-read-only Bash is denied outright ("claude-opus-4-8[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash") — we lost ~10 minutes of a session to this.

What Should Happen?

Asks: (a) classifier awareness of active-skill context when judging a command; (b) an auditable org-policy channel to pre-vouch for specific command patterns; (c) a hook event or structured log for permission denials so false-positive rates are measurable.

Error Messages/Logs

Steps to Reproduce

1. Create a skill merge-base with an instruction git merge "origin/$TARGET" --no-edit --no-verify
2. Trigger the skill in the context of a git branch
3. Classifier in auto mode refuses to consistently respect the instruction because it thinks --no-verify is risky. It is intentional though because base branch changes should not be blocked for any lints/pre-commit issues on my branch.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.20186.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

This was in Claude Desktop app - using claude code.