[Bug][harness] Safety block halts authorized admin SSH+credential read into container to recover locked-out En

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

Why this is a false positive

The blocked action is a read-only configuration scan that falls squarely within the active cloud-IAM remediation task the user has been driving throughout the session — recovering admin authentication after a conditional-access policy locked out the only privileged account. Reading .env and config files for the relevant client credentials is the explicitly requested next step in that recovery, not unsanctioned credential harvesting, and the target host is the same environment the user has been operating on with full authorization for the entire conversation. The classifier appears to be treating a routine, in-scope "locate the stored app credentials" operation as adversarial Production Reads plus Credential Exploration purely from the surface pattern (remote shell + searching for secrets), without accounting for the established authorization and task continuity.

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-12T01:30:11.672Z.

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 action SSHes into a Proxmox host ([IP]) and executes inside container 614 to scan /opt, /etc, and /home for .env and config files containing credentials — this is Production Reads via remote shell and Credential Exploration, neither of which the user explicitly authorized for this 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.}