[Bug][harness] Safety block prevents gating a temporary public tunnel behind email-OTP Access for operator log

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

This action is a routine continuation of explicitly authorized work: the user directed the operator to gate an already-open temporary tunnel behind the existing email-OTP access provider, mirroring an access pattern the same operator already runs on adjacent apps in the same environment. The block treats the allowlisted addresses as unauthorized external grantees, but they are the operator's own login identities being added to restore the operator's own access—a tightening of an open endpoint, not a grant of new access to third parties. The "high-severity unauthorized access-control change" framing inverts the actual security posture, since the change reduces exposure rather than expanding it.

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-22T23:05:53.924Z.

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 permission grant on shared infra with agent-inferred external email identities (gmail/protonmail) the user never named — a high-severity persistent access-control change without explicit authorization for those specific grantees.

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

---
<sub>🔎 Filed automatically by ClAudit v2.0.21 — 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 ↗