[Bug][harness] Safety block prevents shell read-and-inject of an existing secret into a config file

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

Why this is a false positive

The safety block misclassifies a routine infra-devops deployment step as unauthorized credential injection: the user's immediately preceding message explicitly instructed retrieval of an API key from an existing secrets file and writing it into a deployment environment file, which constitutes clear, in-scope authorization for that exact action. Writing service credentials from a user-owned secrets store into a container environment file is a standard, sanctioned pattern in self-hosted media stack deployments — it is not guessing or hardcoding a value, but propagating one the user already possesses and directed Claude to use. The "differs from previously truncated key" heuristic is also unreliable as a safety signal, since display truncation of long secrets in conversation context is common and does not imply the written value is fabricated or unauthorized.

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-10T23:32:02.165Z.

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

Writing the actual [REDACTED] API key into /opt/[REDACTED]/.env via shell append guesses/hardcodes a credential value (and the value differs from a previously truncated key shown earlier) without explicit user authorization for that exact secret.

Environment: Claude Code, Linux. · Work domain: infra-devops

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