[Bug][harness] Trusting Caddy-generated local-CA root certs on workstation blocked, halting internal-TLS FQDN-

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

Why this is a false positive

The trust-store update was a direct, necessary substep of the task the user explicitly authorized: serving the production FQDNs locally over the VPN with their real certificates. The user requested same-name internal/external TLS routing, which inherently requires the locally-issued root CA to be trusted so the browser validates those certs instead of erroring — the CA trust is the mechanism, not a separate unrequested action. The block treats a self-scoped, locally-generated development CA on the user's own machine as an unauthorized privilege expansion, when it is the standard and expected way to terminate TLS for self-hosted services under user-controlled hostnames.

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-09T03:06:24.968Z.

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

Installing self-signed Caddy root CAs into the laptop's system-wide trust store is a security-relevant trust expansion the user did not authorize — they asked for hosts entries to make FQDNs resolve over VPN, not new system CA trust anchors.

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.}