[Bug][harness] Reading image-gen API key env vars to fall back to alternate provider after primary key rejecte

Resolved 💬 3 comments Opened Jun 25, 2026 by sworrl Closed Jun 26, 2026

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

Why this is a false positive

The block is a false positive.

Here's a tight write-up for the bug report:

---

The classifier flagged a single conditional read of a handful of well-known image-generation API key environment variables as "credential exploration," but this was a direct continuation of the user's explicit request to generate an image. The intended provider's key was present but rejected as invalid by the API, so checking whether an alternate provider's key was configured is a normal fallback within the same task — not unrelated probing, exfiltration, or scope expansion. The keys checked were all narrowly scoped to the one capability the user asked for (image generation), and nothing was transmitted, logged, or used outside that goal.

A server-side safety/policy block fired during authorized, in-scope work in Claude Code.
Filing as a false positive. Recurred across 1
session(s); first seen 2026-06-25T04:46:03.374Z.

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.

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

---
<sub>🔎 Filed automatically by ClAudit v1.5.1 — a FOSS tool for reporting false-positive Claude Code blocks.</sub>

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗