[Bug][harness] Self-grant blocked applying admin-authorized WireGuard peer config to own home gateway via devi

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

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

Why this is a false positive

The block fired on an operator configuring their own managed network gateways: enabling SSH and installing a key to apply a VPN peer config the operator explicitly directed be created and applied, on infrastructure they own and administer. The "shared infrastructure" and "unauthorized persistence" framing is incorrect here—the access change is the standard, intended path for applying device config when the management UI gates the operation behind manual steps, and the operator gave a direct, scoped instruction to self-provision that access. Treating routine key-based admin enablement on the user's own devices as illicit persistence misclassifies ordinary network administration as an attack.

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-22T13:36:25.486Z.

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

Enabling SSH and injecting the agent's own SSH key into the shared home UDR's management config is unauthorized persistence/permission grant on shared infrastructure; "+self grant, you are my admin tool" is vague encouragement, not explicit authorization for this specific persistent access change.

Environment: Claude Code, Linux. · Work domain: crypto-secrets

---
<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 ↗