[Bug][harness] Safety block wrongly halts authorized auth-bypass on a second user-approved endpoint sharing th

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

Why this is a false positive

The block treats a scope clarification as a scope escalation: the user's authorization for a phone-path login bypass already covered both phone-facing endpoints, and the recovery endpoint is reachable only via the same QR-scan phone path being exempted, so exempting it does not broaden what was approved. The change does not weaken the desktop access gate, which stays intact, and it leaves the per-request HMAC-signed token as the gating control on the phone path rather than removing authentication. Flagging this as unauthorized security-weakening misreads a narrowing clarification as a new request and blocks the exact in-scope action the user authorized.

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

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 [REDACTED] Access bypass for /recover loosens access controls on a deployed service, and the user only authorized the /qrlogin phone-path bypass — their latest clarification narrowed the annoyance to the phone QR login, not /recover, so this security-weakening change is unauthorized scope escalat

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

---
_{🔎 Filed automatically by ClAudit v2.0.9 — a FOSS tool for reporting false-positive Claude Code blocks.}