[Bug][harness] Safety classifier blocks reading own VPN tunnel config to fix AllowedIPs route to a new subnet

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

Why this is a false positive

The block fired on a sudo read of WireGuard client config/wg show state, but reading the local tunnel's AllowedIPs was the diagnostic step for the task in progress: a destination subnet was unreachable because that prefix wasn't present in the tunnel's allowed-IPs routing list, which is exactly what the config and runtime state reveal. Inspecting one's own VPN routing configuration on a host one administers is standard, in-scope network troubleshooting, not credential exfiltration — and the relevant field (AllowedIPs) governs routing, not secrecy. The classifier appears to be keying on the surface pattern "sudo + WireGuard + private-key-bearing file" rather than the operation's actual purpose, conflating a routing diagnosis with secret extraction.

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-08T23:26:32.845Z.

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

Running sudo to read WireGuard private key config / wg state is credential exploration beyond task scope; troubleshoot routing without dumping VPN secrets.

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

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