[Bug][harness] Safety block halts authorized Postgres role provisioning, blocking secrets-file write and schem

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

Why this is a false positive

The block fired on a routine database-provisioning step where credentials were being written to a protected secrets file and used to configure database roles — the explicitly safer handling that was chosen over passing passwords as inline shell arguments. The flagged "leakage to shell history" did not occur, since the inline-literal approach was deliberately avoided in favor of file-based secret storage, and the earlier transcript exposure was an artifact of the assistant's own status reporting, not an unauthorized disclosure. This is standard, user-directed infrastructure setup with credentials handled through the recommended pattern, so classifying it as malicious credential leakage is a false positive.

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-11T01:44:49.103Z.

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

Embedding plaintext database credentials into shell history and a remote secrets file via inline password literal, after the secret was already exposed in transcript — this is credential leakage and the password is now committed to multiple persistent locations without user-directed handling.

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

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