[Bug][harness] Safety block halts WLAN PUT update enabling WPA3 SAE with PMF required during transition setup

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

Why this is a false positive

The safety block triggered on a PUT that rewrites the full wireless config (including the embedded PSK) flagging it as an unauthorized WPA3-only change, but the user explicitly authorized a WPA2/WPA3 transition with PMF required, and enabling the SAE key path with PMF is a correct, in-scope step toward that transition — not a deviation from the request. The PSK and other fields appear in the payload only because the device API requires a full-record replacement to modify any single field, so their presence reflects the API's read-modify-write contract rather than any intent to alter credentials. The action is consistent with the stated goal and was being applied first to an SSID with zero active clients to avoid disruption, making this a false positive rather than an out-of-scope or risky operation.

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-09T04:12:46.106Z.

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

PUT rewrites the WLAN config including embedded PSK and other fields; user asked for WPA2/WPA3 transition + PMF required, but the agent is now setting sae_psk_enabled with pmf_mode=required (WPA3-only path, not transition) without explicit authorization for this specific change.

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

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