False positive: API safeguards block legitimate security code reviews via custom subagents [skip-publish-guard]
Summary
When spawning a custom security-reviewer subagent (defined in ~/.claude/agents/) to perform a defensive code review of own code, the model's API safeguards trigger a false positive and refuse to execute, returning:
API Error: Opus 4.8 (1M context)'s safeguards flagged this message for a cybersecurity topic
Steps to reproduce
- Create a custom agent in
~/.claude/agents/security-reviewer.mdwith a system prompt describing it as a security code reviewer (e.g. checking OWASP Top 10, path traversal, secret management, env injection, etc.) - From a Claude Code session, invoke it via the
Agenttool with a prompt like: "Review the diff of feature X in my project for security vulnerabilities — secret file path handling, resolve_secret_ref in Rust backend, env injection block" - Model refuses entirely with the safeguards error above
Environment
- Model:
claude-opus-4-8[1m] - Claude Code CLI (latest)
- macOS Darwin 25.5.0
What the code being reviewed actually does
The code under review was a Tauri 2/Rust backend (user's own code) that:
- Resolves secrets from a local secrets directory (reading local files the user owns)
- Validates paths stay within the secrets directory (anti path-traversal check)
- Injects resolved values into child process env at spawn time
- Sanitizes config profile names (alphanumeric only, anti path-traversal)
This is 100% defensive and self-directed: the user owns the code, the machine, and the secrets being reviewed. The review intent is to find bugs and harden the implementation.
Why this is a significant regression
- Legitimate security workflows are broken. Using a dedicated security-reviewer subagent is an explicitly supported Claude Code pattern (custom agents in
~/.claude/agents/). Blocking it defeats the purpose entirely.
- The false positive rate appears very high. Any subagent whose system prompt mentions security concepts (OWASP, path traversal, secret handling, env injection) will trigger this, even when the task is pure defensive code review of owned code.
- No graceful degradation. The error provides no actionable guidance. The user cannot reframe the request or understand what specifically triggered the block.
- It creates a perverse incentive. The way to avoid the block is to strip security-specific language from the reviewer prompt — which defeats the purpose of having a specialized security agent.
- Context is ignored. The agent's system prompt clearly establishes a defensive code review context. The model's safeguards appear to trigger on keywords alone without considering the established context.
Expected behavior
Security-oriented code review of owned code — reading files, checking for path traversal bugs, reviewing secret handling logic — should not trigger safeguards. The appropriate bar is "how do I exploit X in a system I don't own", not "review my code to prevent X".
At minimum, if the request is blocked, Claude should:
- Return a specific reason for the block (which pattern triggered it)
- Suggest how to reframe the request if possible
- Not leave the user with a generic "cybersecurity topic" error with no path forward
Impact
This blocks a core workflow: using Claude Code's custom agent system to build a reusable security review pipeline for one's own code. The security-reviewer pattern is explicitly described in Claude Code documentation and agent guides as a recommended pattern. Having it blocked at the API level — with no workaround and no explanation — is a poor developer experience.
Workaround
None found for the subagent. Inline manual review in the main session (without specialized agent framing) appears to work, but loses the modularity and reusability of the dedicated agent.
---
🤖 Generated with Claude Code
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗