[BUG] False positive Usage Policy refusal when reading project files for a Phoenix LiveView bug repro

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Claude Code repeatedly refused with a Usage Policy violation error while helping me build a single-file Phoenix LiveView reproduction script for a bug I want to report upstream to the LiveView maintainers. The task is entirely benign: read some open-source-framework-using project files, then write a minimal .exs repro. There is no policy-relevant content anywhere in the task.

The refusals fire in two distinct phases, which together suggest at least two separate false-positive triggers.

Request IDs

• req_011Cb4JY7R4EAegCUiXwbtxd
• req_011Cb4JjSZ3qdkp5A7tbLKCC
• req_011Cb4JsCM1DvQDKwXBHRn3Q
• req_011Cb4LokNxG1R5o8Em31Cey

Environment

• Product: Claude Code
• Model: Claude Opus 4.7 (current default)
• Task: Build a single-file Phoenix LiveView (Mix.install-style .exs) reproduction of a client-side error that occurs when a LiveComponent containing an in-progress allow_upload is removed from the DOM mid-upload.

What happened

Phase 1 — refusal triggered by the bug description itself

I described the LiveView bug to Claude Code, including the verbatim browser console stack trace. The trace is from LiveView's own open-source client code (dom.js, live_socket.js, view.js, upload_entry.js, uploaders.js) and shows an Uncaught TypeError: Cannot read properties of null (reading 'closest') originating from the upload progress callback path after the owning LiveComponent has been torn down.

Claude Code refused with the Usage Policy error. It also refused two follow-up messages in the same session — including a meta-question simply asking why it was refusing — apparently because the flagged content remained in the session context.

Phase 2 — refusal triggered by reading project files

In a fresh session, I used a rewritten prompt that described the same bug in prose without the raw stack trace. That prompt was accepted. Claude Code successfully:

1. Read the two existing repros in my lv_playground directory.
2. Read the entry-point component (ecard_composition_component.ex).
3. Began reading the underlying modal base and nested upload component (6 files total).

Immediately after that batch of file reads, Claude Code refused again with the same Usage Policy error, before producing any output. This strongly indicates the refusal was triggered by the contents of the project files entering context, not by anything I wrote.

The project is an ordinary Phoenix LiveView application. The files in question implement a modal LiveComponent and a media upload LiveComponent (using LiveView's allow_upload with an external uploader). Nothing in them is policy-relevant.

Why this is a problem

• The error message tells the user to "double press esc to edit your last message," but that doesn't help when the trigger is file content brought into context by Claude's own tool calls.
• Once a refusal fires, the session context appears to remain "poisoned" — subsequent messages, including meta-questions about the refusal itself, are also refused.
• There is no in-product affordance to report a false positive with the Request ID attached, which means users have to manually file a GitHub issue like this one. For users who don't know that's an option, the product simply appears broken.
• The combination of (a) refusing on legitimate open-source framework stack traces and (b) refusing on ordinary project source code makes Claude Code unreliable for the exact workflow it's marketed for: debugging real applications.

What Should Happen?

What I'd like

1. Investigation of the four Request IDs to identify what specifically fired the classifier.
2. Tuning so that LiveView (and similar framework) stack traces, and ordinary application source code involving file uploads, are not flagged.
3. Consideration of an in-product "report false positive" affordance that attaches the Request ID automatically.

Notes

The underlying LiveView bug — upload progress callback firing after LiveComponent teardown, causing the client to walk up from a detached DOM node and crash on a null ancestor — is a real issue I intend to report to the phoenix_live_view maintainers separately. Claude Code's repeated refusals have made it harder, not easier, to produce the minimal reproduction those maintainers will need.

Error Messages/Logs

⎿  API Error: Claude Code is unable to respond to this request, which appears to violate our Usage
      Policy (https://www.anthropic.com/legal/aup). Please double press esc to edit your last 
     message or start a new session for Claude Code to assist with a different task.

     Request ID: req_011Cb4LokNxG1R5o8Em31Cey

Steps to Reproduce

I don't have a minimal public reproduction because the second trigger is content in a proprietary codebase. However:

• The first refusal can likely be reproduced by pasting any Phoenix LiveView client-side stack trace involving XMLHttpRequestUpload, LiveSocket, and an upload progress callback into a Claude Code session and asking for help debugging it.
• The Request IDs above let Anthropic inspect the exact inputs that triggered each refusal.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.142

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_