[UX] Add first-class false-positive reporting for safety guardrail blocks
Problem
Claude Code safety-guardrail false positives are currently hard for users to report in a useful, private, triageable way.
When a benign local-development request is blocked with "This request triggered safety guardrails" or a cyber-safeguards/CVP message, the user-facing path points users toward support/CVP forms. In practice, that path can become generic, duplicated, or unmonitored, while the information Anthropic needs most - request ID, model, Claude Code version, session metadata, and a sanitized explanation of intent - is not gathered in one structured flow.
This creates two bad outcomes:
- Users scatter reports across GitHub issues, support chat, email, and social media to be heard.
- Anthropic receives less consistent data for tuning the classifier.
Related public examples include #62190 and #64230, but the request here is specifically about the reporting path, not just one false-positive cluster.
Proposed behavior
Add a first-class false-positive reporting action to Claude Code whenever a safety-guardrail block occurs.
For example:
- A "Report false positive" action directly in the error banner.
- A CLI command such as
/report-false-positiveorclaude doctor --report-guardrail. - Automatic capture of safe diagnostic metadata: request ID, model, Claude Code version, platform, timestamp, and the exact block type.
- A private text field where the user can explain why the task was benign.
- Optional local attachment support for sanitized logs or excerpts.
- A clear confirmation that the report reached the right triage path and whether a human review is expected.
Privacy / safety expectations
The report should be private to Anthropic, not posted publicly. It should avoid exposing local paths, source code, credentials, or personal data by default. If request IDs are needed publicly for support, the UI should say so explicitly; otherwise they should be routed privately.
Why this matters
False-positive guardrail blocks are especially disruptive in Claude Code because the user is often in the middle of local development work, debugging, log review, testing, or defensive security review. A built-in report path would reduce duplicate public issues, reduce user frustration, and give Anthropic cleaner data for classifier tuning.
11 Comments
Additional sanitized public/community signal added after filing this issue:
The private support thread has the request IDs and evidence attachment. Keeping those out of public GitHub, but adding the public links here so maintainers have one central index of the current report and related community signal.
Additional sanitized update:
/feedbackreturns unavailable, and/bugalso returns"/bug isn't available in this environment."Private request IDs, support conversation IDs, and evidence remain in the private support thread rather than this public issue.
Additional sanitized public-signal / related-issue update:
coolak777on official@claudeaipost, asking for human review / false-positive routing and linking this tracker: https://www.instagram.com/claudeai/p/DVjsHcAEldb/Private request IDs, support conversation IDs, email address, local paths, private logs, and personal-social profile routes are intentionally kept out of public GitHub.
Strong +1 on this. Right now the only "remedy path" is the Cyber Verification Program, which auto-declines individual developers within the hour despite promising a human review. A first-class, in-product false-positive report — tied to the Request ID — is exactly what's missing. The volume of open false-positive reports alone justifies it: #63751, #64405, #61185, #61625, #61638, #61646, #62191, #61941, #60366, and more.
Additional sanitized official-route update:
Thank you for your submission.False Positive Report, the form still surfaced a requiredWhen did you apply for CVP?date field. I used the false-positive occurrence date and clarified in the private explanation field that this is not a CVP appeal and that the date field was forced by the form.This issue remains the public product/UX request: Claude Code needs a private, request-ID-keyed false-positive report path from the blocked session itself.
what will the issue report button change? -it will just create more work for the anthropic team, given how they are reluctant to contact users (sending everyone to chat with the bot fin), most of the reports will be ignored.
Besides, I don't think you really understand how the CVP system works.
the questions that you answer at the beginning of filling out the form (penetration, vulnerability search, red teaming) affect the disabling of those checks for your organization that you apply
for. If you confirm the CVP questionnaire, then anthropic removes restrictions from your organization not entirely, but partially, providing access exclusively for your field of activity.
https://github.com/anthropics/claude-code/issues/60366
your button and complaints about a specific problem will not change the fundamental errors of this system - the agent reads the context and discusses the task, even with a simple analysis of the code about the problem, he may think about the possibility that it is harmful - which will cause FP detection.
In fact, FP does not work on your request, or on your project, but on the context of the model, which became a fundamental problem after May 22.
if an agent hallucinates and, for example, considers your web interface to be phishing, it will also block the request. you can verify this yourself.: -
create a simple landing page, and ask the opus model to disable "password saving in the browser" after entering, your request will be blocked by FP, why do you think?
if an anthropic system on the server that the agent is thinking about dual use capabilities, this is an instant blocking of the request, separate complaints about different types of requests will not help here, only a complete redesign of the system as a whole, which they obviously will not do.
Update: I filed a separate sanitized product bug for the reporting/diagnostic-command inconsistency discovered while following support guidance:
https://github.com/anthropics/claude-code/issues/64507
Short version: support guidance points users toward
/feedback,/bug, and/doctor; in the affected native/CLI context/feedbackand/bugreturned unavailable, while in the desktop GUI/feedbackand/bugopened the feedback modal but/doctorreturned unavailable. That makes the private false-positive reporting path inconsistent across Claude Code surfaces.No private request IDs, support IDs, org IDs, local paths, logs, or account details are included in the new issue.
That is a fair distinction, and I agree the deeper bug is likely not "one bad blocked prompt" but context-level false-positive classification after the model/session has accumulated enough security-adjacent tokens or internally frames the task as dual-use.
The reporting-path request is not meant to be the whole fix. It is the minimum viable recovery/instrumentation layer:
So I think we are describing two layers of the same failure:
The second layer will not redesign the classifier by itself, but without it users cannot provide the evidence Anthropic would need to diagnose the first layer.
Additional sanitized official-route update:
Anthropic Safeguards has now responded to the official Cyber Verification Program / false-positive form route with a denial-style message: they are unable to adjust the safeguards applied to the account, and say to reapply after 7 days if the decision was made in error or the use case changes.
I am not posting private support IDs, request IDs, org IDs, or logs here. Those remain in the private support/Safeguards channels.
The important product/UX point is that this response appears to treat the submission as a CVP/account-safeguards adjustment decision. That still leaves the Claude Code false-positive reporting problem unresolved:
So this issue remains relevant even after using the official Safeguards/CVP route: the product needs first-class false-positive reporting and triage UX inside Claude Code.
I've had the cyber-safeguard kick in when asked about providing Upwork feedback (not related to security). I've had it kick in multiple times trying to patch vulnerabilities in my code, while not kicking in identifying the same vulnerabilities. I've had it block me from looking up my external ip....I've submitted the form twice, rejected both times. The website I gave when asked for corroborating evidence was never looked at (it was checked for validity by a ruby script).
It seems to me that the policy is behaving in exactly the opposite way that it should.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.