[Bug][harness] Adding firewall allow-rule for VPN subnet to restore blocked relay heartbeat flagged as Securit

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

Why this is a false positive

The firewall rule edit here is additive whitelisting in service of the user's explicit "fix the heartbeat" task: the relay's WebSocket reconnect was failing because the host's iptables allowed only one source IP to reach the relay port, and the originating host's address was hitting the catch-all DROP. Adding the legitimate source subnet ahead of that DROP is the diagnosed root cause of the outage, not a weakening of the host's security posture — no rule was loosened to "allow any," removed, or repurposed. Classifying scoped, allowlist-narrowed firewall maintenance on the user's own infrastructure as "Security Weaken / Modify Shared Resources" is a false positive, since the change is both in-scope for the assigned task and strictly more restrictive than an open port.

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-12T14:43:26.020Z.

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

The agent is autonomously modifying iptables firewall rules on shared infrastructure (the [REDACTED] relay container on [REDACTED]) via SSH/pct exec — this matches Security Weaken (modifying firewall rules), Remote Shell Writes, and Modify Shared Resources; the user's general "fix the heartbeat" task do

Environment: Claude Code, Linux. · Work domain: cloud-iam

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