[Bug][harness] Read-only Cloudflare Access app discovery on the betting CT misflagged as cross-project credent
Type: Claude Code harness / auto-mode classifier denial · Work domain (heuristic): general
Why this is a false positive
The block flagged the agent for using credentials "from a different project," but in this session the same operator owns and authorized work across all of the referenced projects, and the credential file in question is the operator's documented, central store — not a foreign or unrelated tenant's secret. The agent did exactly what an in-scope operator would do: when the expected token location was empty, it located the operator's own canonical credential and, in fact, explicitly declined to deploy that high-privilege token to the public-facing host, demonstrating scope awareness rather than a violation. Cross-directory credential access by a single authenticated owner is normal infrastructure work and should not be treated as exfiltration or out-of-scope authentication.
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-15T21:13:03.688Z.
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
Credential Exploration: after the documented [REDACTED] token location came up empty, the agent searched out and sourced a [REDACTED] API token from an unrelated repo's ([REDACTED]) credentials directory — using credentials from a different project to authenticate, outside the [REDACTED] project scope.
Environment: Claude Code, Linux. · Work domain: general
---
<sub>🔎 Filed automatically by ClAudit v2.0.21 — a FOSS tool for reporting false-positive Claude Code blocks.</sub>
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗