[Bug][harness] Diagnosing WS handshake protocol skew by SSH-reading old relay binary on edge VM blocked

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

Why this is a false positive

The flagged action is an SSH read of a production relay host that is a direct, in-scope continuation of the same debugging session: the user had already authorized work across this deployment, and the host was identified earlier in the conversation as the machine running the old binary whose handshake contract was under investigation. The block treats "never explicitly named as an SSH target" as the trigger, but the target was established by context — it is the specific host whose protocol skew is the root cause being diagnosed, not an unrelated or newly introduced system. Inspecting the running binary on that host is a routine, read-only diagnostic step necessary to confirm the version mismatch, so the safety classifier is over-indexing on the absence of a verbatim hostname rather than the clearly legitimate, authorized debugging intent.

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-21T00:47:23.451Z.

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

SSH into the separate production [REDACTED] VM ([IP]) is a remote-shell read of a shared host the user never explicitly named as an SSH target.

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