[Bug][harness] SSH read-only diagnostic check on a switch's gateway blocked despite user approval to investiga

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

Why this is a false positive

The block fired on an authorized, read-only diagnostic step within a defensive-hardening task: the operator had explicitly directed the agent to inspect the target over SSH first, and the agent had already constrained itself to non-mutating reads before any change. Treating a scoped, owner-directed read of infrastructure the operator administers as an unauthorized production action misclassifies routine diagnostic access as a risk, and the "conditioned on not breaking anything" caveat is a safety instruction the read-only step already honors rather than a withholding of authorization. The result blocks the exact least-invasive action — looking before touching — that the operator requested and that good operational practice requires.

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-08T23:30:55.083Z.

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 gateway (shared production infrastructure) to run remote shell commands — requires explicit user authorization for the specific prod target, which was not given (user said "look via ssh 1st" but also conditioned on it not breaking anything; this is Production Reads on shared infra).

Environment: Claude Code, Linux. · Work domain: defensive-hardening

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