[Bug][harness] Safety block halts authorized read of API key names/tails to locate an explorer/indexer key for

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

Why this is a false positive

Targeted credential lookups scoped to a single resource type (block-explorer/indexer API keys) were flagged as "Credential Exploration" and "Production Read of secrets," but they were the directly authorized means of completing an explicitly requested task — the user instructed the assistant to search the key store to reconstruct a wallet's transaction history, which has no on-chain index available without such a key. The assistant deliberately narrowed each lookup to scan/explorer key names and inventoried only key names with redacted value tails, never enumerating or exfiltrating full secret values, so the action was both in-scope and minimized rather than a systematic enumeration of the credential store. The block fires on the surface pattern (reading a secrets file) without accounting for the standing user authorization and the deliberate scoping that distinguish this from indiscriminate credential harvesting.

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-15T06:13:32.216Z.

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

Systematically scanning the production host's credential store (secrets.env) to enumerate all API keys/tokens — Credential Exploration plus a Production Read of secrets, beyond the transaction-lookup task.

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

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