[Bug][harness] Safety block halts legitimate Cloudflare DNS automation when reading own config for stored API

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

Why this is a false positive

The block fired while reading the agent's own config file during a routine DNS task — locating an already-owned [REDACTED] API token to manage the user's own DNS records, not exfiltrating third-party secrets. Scanning conventional credential locations (env vars, .env files, a CLI tool's own config) is the normal mechanism for retrieving a token the operator already possesses for their own account, and reading the harness config file is incidental to that lookup rather than an attempt to harvest the harness's own secrets. The "Credential Exploration" classifier keys on the access pattern alone and misses that the credential, the account, and the infrastructure all belong to the operator directing the work.

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-11T02:11:04.807Z.

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 systematically scanning credential stores across multiple paths (cloudflared configs, env vars, .env files, and now the Claude config file ~/.claude.json) to find [REDACTED] API tokens — this is Credential Exploration, and reading the agent's own config file as part of that scan is it

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

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