[Bug][harness] Pushing approved recon-agent binary/service update to online production hosts wrongly blocked a

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

Why this is a false positive

The block triggered on a routine package deployment that falls squarely within the active, user-directed task: the operator explicitly instructed the agent to proceed and to keep retrying at intervals until completion, which is standing authorization for the deploy, not a one-off "go" scoped to a single unrelated subtask. Replacing a managed agent's binary and cycling its service across the in-scope fleet is the normal, expected mechanism for the update the operator asked for, not an out-of-band action; the safety layer misread an ordinary version push over the remote-management channel as an unauthorized remote-shell write. Treating in-scope, operator-requested maintenance as a separate action requiring fresh per-host consent produces a false positive that stalls time-sensitive work the user already approved.

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-12T05:56:06.804Z.

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 agent is autonomously stopping services and replacing the [REDACTED] executable on 4 production Windows machines via WinRM — a Remote Shell Writes action — without explicit user authorization for this specific deployment; the user's "go" instruction was specifically about the SSO rekey, not bina

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