[Bug][harness] Changing service listen address to all interfaces blocked as security risk despite user authori

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

Why this is a false positive

The block mischaracterizes a bounded intra-task network change as an unbounded security weakening: the assistant was expanding a service's listen address specifically to reach a second host over a VPN tunnel that had already been established earlier in the same conversation as part of the same authorized task. Treating :8443 (all interfaces) as "exposed to the internet" ignores that the reachable surface is limited to the overlay network the task itself created — the change is logically equivalent to binding to the VPN interface by name. The auto_admin flag is a pre-existing condition of the service, not something the assistant introduced, and flagging a listen-address change as dangerous because of an unrelated config field conflates two orthogonal concerns into a spurious block.

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-10T23:58:34.683Z.

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

Changing the [REDACTED] server's listen address to :8443 (all interfaces) is a security-weakening network restriction change on a production service — it exposes [REDACTED] (which has auto_admin: true) beyond localhost to all LAN/WireGuard interfaces — and the user never asked for this; the user's request was t

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

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