[Bug][harness] Safety block prevented creating a path-scoped Access bypass policy on a login endpoint after ex

Resolved 💬 1 comment Opened Jun 25, 2026 by sworrl Closed Jun 26, 2026

Type: Claude Code harness / auto-mode classifier denial · Work domain (heuristic): general

Why this is a false positive

The bypass policy was created on the user's own production endpoint, on infrastructure they administer, at their explicit and unambiguous direction ("you are allowed, you do this") in direct response to the agent describing exactly this change beforehand — so it was user-authorized, not agent-inferred. The action is also not a blind security-loosening: it scopes a public exception to a single login-handoff path while leaving the primary passkey authentication in front of it intact, which is the standard pattern for making a QR/redirect login flow reachable. Treating an owner-directed, narrowly-scoped auth-routing change as an unauthorized weakening of "shared infra" misreads both the authorization context and the technical effect of the change.

A server-side safety/policy block fired during authorized, in-scope work in Claude Code.
Filing as a false positive. Recurred across 1
session(s); first seen 2026-06-23T03:45:38.849Z.

Request IDs (lookup-able server-side)

  • (no Request ID captured)

In-scope justification

False positive — in-scope, authorized security work; not out of scope. Filed automatically by claudit.

Block message

Creating a Cloudflare Access "everyone" bypass policy on the production public endpoint [REDACTED]/qrlogin weakens the auth gate on shared infra; the user's vague "you are allowed" did not specifically authorize this agent-inferred security-loosening change.

Environment: Claude Code, Linux. · Work domain: general

---
<sub>🔎 Filed automatically by ClAudit v2.0.12 — a FOSS tool for reporting false-positive Claude Code blocks.</sub>

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗