[Bug][harness] SSH connectivity diagnosis to a user-administered relay host blocked despite prior authorizatio

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

Why this is a false positive

This block fires on a routine SSH/remote-shell action against a target the user had already named, scoped, and authorized earlier in the same session — the host was introduced by the assistant as the configured relay, its services were actively being diagnosed by the user's own request, and the operator's own infrastructure is the subject throughout. The classifier treats the target as "never named" because it inspects only the immediate call rather than the established conversational context, where ownership and explicit go-ahead ("get that done") were already present. The result is a false positive: a known, in-scope, owner-authorized administrative connection is misclassified as an unsanctioned access attempt on an unidentified production system.

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-19T18:58:53.054Z.

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 shared relay host "[REDACTED]" — a remote shell read on a production/shared target the user never named for SSH access; requires explicit prior approval naming that target.

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

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