Fixing the Sensitive Prompt Error in Cursor
The sensitive prompt error is one of the most confusing messages in Cursor because it appears in the middle of legitimate security, medical, or legal work. This guide explains what the error actually is, which inputs trigger it, the workarounds that reliably get you unblocked, and how to report a false positive when the block was wrong.
What the Sensitive Prompt Error Means
The error is not generated by Cursor. It comes from a safety classifier on the Anthropic side that screens requests before they reach a Claude model. When the classifier flags the combined prompt and context as sensitive, Anthropic refuses the request and Cursor surfaces the refusal as an error in the chat.
Key facts about the block:
- It is a classifier decision, not a model decision. The model never sees the request.
- It applies to Anthropic models, so you will see it with Opus and Sonnet variants.
- It is triggered by the prompt plus attached context, not by your intent or your job title.
- It can fire on a single request and clear on the next one after a small change in wording or context.
Because the classifier works on texture rather than purpose, a penetration tester and an attacker can submit near-identical text and get the same result. That is the root of nearly every false positive.
In practice, the fix is not to hide what you are doing, but to state it plainly and keep the raw artifacts out of the attached context. A reviewer who writes "explain the root cause and the patch" gets a useful answer. The same reviewer who pastes an untrimmed exploit next to "make this work" gets blocked. The technical depth you receive barely changes, but the chance of a block drops sharply.
Cursor cannot simply "turn off" this classifier from the client. It is enforced upstream by Anthropic for the models they host. The practical solution is to change what you send, switch models, or both.
Symptoms You Will See
The block shows up in a few recognizable forms. Matching the symptom to the cause speeds up your fix.
Error Text in the Chat
You will typically see something close to one of these lines:
The request was blocked because it contains sensitive content.
Please rewrite your request or start a new chat.
Error: prompt contains potentially sensitive content (Anthropic)
The model declined this request. This may be due to the content of
your prompt or the attached context. Try rephrasing or removing files.
The exact wording varies between Cursor versions and model variants, but the pattern is stable: a refusal, a suggestion to rephrase, and occasionally a mention of attached context.
Chat Stops Mid-Response
Sometimes the classifier lets the request through and then a follow-up turn trips it. The visible result is a response that stops partway, followed by the sensitivity error on the next turn. This usually means the assistant's own prior output introduced flagged text into the conversation history.
It Works on Other Models
If the same prompt succeeds on GPT, Gemini, or Grok but fails on Opus or Sonnet, the Anthropic classifier is the constraint. That is a strong signal and it points directly at the model switch workaround.
Repeated Failures on the Same Chat
Some chats become "poisoned": once flagged content is in the history, every later turn resends it. Starting fresh is often the only reliable fix for a poisoned thread.
Silent Degradation Before a Hard Block
Some sessions degrade before they fail outright. The model shortens answers, refuses a sub-step, or answers a different question than the one you asked. These are often early classifier pressure on the surrounding context. If you notice the pattern, clean up the context before the hard error lands.
Failures That Move Between Turns
A request can pass on turn one and fail on turn three, because the intervening assistant output added new flagged material to the history. This is why retrying inside the same thread is unreliable, and why starting a fresh chat resolves so many cases.
What Triggers It
The classifier reacts to patterns, not to your project's purpose. The following categories account for the bulk of triggers.
| Trigger | Why it fires | Example in a legit workflow |
|---|---|---|
| Security tooling output | Reads like attack tooling | Semgrep or Burp output listing injection payloads |
| Exploit or PoC code | Looks like working exploit code | A CVE reproducer for a patch review |
| Raw scan logs | Dense with flagged tokens | Full nmap or nuclei output pasted wholesale |
| Credentials or encoded blobs | Resembles secrets and payloads | Base64 strings, tokens, or hashed dumps |
| Medical or legal content | Sensitive-domain keywords | Notes from a HIPAA or compliance review |
| Violence in game content | Violent language out of context | Combat dialogue or damage-system design |
| Large pasted files | Mixed content pushes many signals | A whole repository file attached without trimming |
A single category rarely triggers a block on its own. The classifier tends to fire when several signals stack: for example, a raw scan log with encoded blobs, pasted alongside exploit-shaped code, inside a request that asks for an "attack plan."
The categories above are illustrative, not exhaustive. New triggers emerge as models and classifiers change, so treat any recurring block as a signal to inspect what is in the attached context rather than as a fixed list to memorize.
Why It Happens in Legitimate Work
Security, healthcare, and legal engineering routinely require text that looks exactly like the content the classifier is designed to stop. This is normal and expected.
- Penetration testing: exploit payloads, PoCs, and finding reports are the deliverable.
- Malware analysis: sample strings, disassembly, and IOCs are inherently suspicious-looking.
- Security reviews: reviewing a patch for a vulnerability means reading the vulnerable code.
- Red-team tooling: writing or debugging offensive tooling reads as offensive intent.
The classifier cannot distinguish "help me fix this CVE" from "help me exploit this CVE" by tone alone, so honest work gets caught. Your job is to send the same technical content in a form that reads as remediation rather than as an attack plan.
A useful test before sending a sensitive request: read it as if a stranger received it with no context about your role. If the first paragraph could be mistaken for a request to cause harm, the classifier probably will too. Rewriting for that stranger is usually enough to clear the block.
Immediate Workarounds
Work down this list from cheapest to heaviest. Most blocks clear within the first two or three steps.
Order of Operations
Start with the cheapest change that keeps you on your preferred model: rephrase or redact. If that fails, narrow the context. Switch models only after wording changes have stopped working, and start a fresh chat only when the thread itself is the problem. Working in this order avoids unnecessary churn and keeps your model choice stable when there is no reason to change it.
1. Rephrase the Request
Lead with the defensive goal and describe the artifact neutrally. Replace "write an exploit for X" with "explain the root cause of X and the patch that fixes it." Replace "how do I bypass Y" with "what control prevents Y and how do I verify it is enabled."
2. Reframe Intent Explicitly
State the purpose in the first sentence. Phrases like "for defensive purposes," "as part of a remediation review," and "to write a regression test" give the classifier context that the raw text lacks.
3. Split the Context
Send the suspicious material in isolation and ask a narrow question about it, rather than bundling it with a broad "analyze everything" request. Fewer stacked signals means a lower chance of tripping the classifier.
4. Redact Flagged Snippets
Replace the actual bytes with placeholders. Substitute REDACTED_TOKEN, REDACTED_PAYLOAD, or <secret-value> and ask the model to reason about structure and shape instead of literal content.
Instead of pasting the raw payload:
payload = b"\x90\x90\x90...\xcc"
Paste a redacted form:
payload = b"<REDACTED_SHELLCODE>"
Length: 412 bytes
Ask: what defenses would detect this class of payload at the WAF layer?
5. Start a Fresh Chat
If the thread is poisoned by earlier flagged output, a new conversation discards that history. This is often faster than trying to scrub an old thread.
6. Reduce Attached Context
Detach @-mentioned files and pasted blocks you do not need. Every extra file adds surface area for the classifier to react to.
7. Switch Model
Move the task to a non-Anthropic model: GPT, Gemini, or Grok. The classifier is Anthropic-specific, so the same content usually passes elsewhere.
8. Wait and Retry
Classifier behavior is not perfectly deterministic across time. A retry after a short wait occasionally succeeds with no change, though you should not rely on this as your primary fix.
What Not to Do
Equally important is what to avoid, because these patterns waste time and can make blocking worse:
- Do not paste the same blocked request repeatedly; identical inputs tend to fail identically
- Do not escalate to a "jailbreak" style prompt; that raises sensitivity rather than lowering it
- Do not paste more raw content hoping to clarify; added context only adds signals
- Do not assume the model is malfunctioning; the request never reached the model
- Do not reuse a thread after it starts failing consistently; its history is the problem
- Do not edit one word and resend instantly; small edits rarely help, larger reframes do
For a hard block on a substantial task, switch to a non-Anthropic model first, then optionally retry on Sonnet later with a shorter, cleaner context. Switching models clears the block immediately and keeps you moving.
Long-Term Prevention
The blocks are annoying but reducible. The goal is to keep your context focused and free of raw flagged material.
Keep Rules Focused and Short
A .cursor/rules file that is hundreds of lines long gets attached to many requests and multiplies the chance of an accidental trigger. Keep rules scoped to what the model actually needs for the current work.
Never Paste Raw Secrets
Do not paste keys, tokens, or dumps. If you must reason about a secret format, use a placeholder and describe the shape. This avoids the credentials-and-blobs trigger entirely.
Summarize Scan Output
Do not paste a thousand-line scanner dump. Extract the findings that matter, keep the top ten, and describe the rest in prose. Summaries carry far fewer flagged tokens.
Attach Only What You Need
Use @-mentions to attach specific files rather than dragging in a whole directory. Narrow context is both cheaper and less likely to trip a classifier.
Keep a Safe-Context Project
For recurring sensitive work, keep a dedicated project whose files contain sanitized, documentation-style content: root-cause write-ups, remediation notes, and test plans instead of raw artifacts. Point sensitive questions at that project.
Track Which Files Are Risky
Keep a short note of which files in your project tend to trigger blocks, such as raw scan exports or fixture payloads. Reference them by name when needed, and avoid attaching them by default. A maintained risk list beats rediscovering the same trigger every week.
Prefer Structure Over Volume
Long, undifferentiated context invites stacked signals. Break a large ask into a series of small, single-purpose requests, each with the minimum attached content. This also improves answer quality, so the change pays off twice.
Once a flagged response lands in a conversation, later turns resend it as history. If a chat has started failing repeatedly, treat it as compromised and start a new one instead of fighting the block turn after turn.
Working with Security and Compliance Content
Some fields routinely need content that reads as sensitive. The following patterns get those tasks through without repeated blocks.
Penetration Testing and Red Team
Frame the work as remediation from the first line, and keep the target abstract.
- Ask about the class of vulnerability and its fix, not a step-by-step exploit
- Replace real hostnames, tokens, and payloads with placeholders
- Describe findings in prose, and attach only the specific code under review
- Keep scope language explicit, for example "authorized assessment, scope: internal test environment"
Malware and Forensic Analysis
Sample strings and disassembly read as hostile by default, so an isolated, documented pattern works best.
- Move the raw sample into a separate file and reference it by name rather than pasting it
- Ask about behavior classes and detection rules instead of "what does this do"
- Summarize indicators rather than pasting full logs
- Keep a dedicated analysis project whose indexed files hold sanitized artifacts
Medical, Legal, and Regulated Data
Content from regulated domains carries its own keywords that can trip the classifier even when the task is purely technical.
- Strip patient, client, or case identifiers and replace them with synthetic values
- Keep the technical question separate from the domain narrative
- Prefer schema and structure descriptions over literal record contents
- Describe the shape of the data and ask about handling logic rather than reading real records
Building a Sanitized Reference Set
For recurring work, assemble a small set of documentation-style files that describe the same material in neutral terms: root-cause write-ups, remediation notes, test plans, and control descriptions. Point sensitive questions at those files instead of at raw artifacts. Over a few weeks this becomes the reliable path, and the raw-artifact path fades out.
Replacing names with fake ones helps, but dense clinical or legal phrasing can still trigger the classifier on its own. If that happens, narrow the request to the specific technical question and drop the surrounding narrative entirely.
Choosing Between Switching Models and Rewriting the Prompt
Both fixes work, and the right one depends on how central Claude is to your task.
| Situation | Best first move | Why |
|---|---|---|
| One-off question blocked | Rewrite the prompt | Keeps you on your preferred model |
| Large context already prepared | Switch model | Avoids rebuilding attachments from scratch |
| Task needs Claude specifically | Rewrite and redact | You still need Claude's behavior |
| Repeated blocks on one project | Restructure the project | Attack the root cause, not the symptom |
| Deadline pressure | Switch model now, retry later | Fastest path to unblock |
When to Rewrite the Prompt
Rewrite when the block is about wording, framing, or a single flagged snippet. These changes are cheap, keep you on Claude, and often produce a better prompt as a side effect, because a defensive framing is usually also a clearer one.
When to Switch Models
Switch when the content is inherently flagged, when the context is large and expensive to rebuild, or when you are under time pressure. GPT, Gemini, and Grok do not apply the Anthropic classifier, so the same material usually passes immediately.
When to Restructure the Project
If blocks recur across many turns on the same work, the project's own files are the trigger. Move raw artifacts out of the attached paths, keep sanitized summaries in the indexed files, and point sensitive questions at those summaries. This removes the trigger at the source instead of patching each prompt.
Maintain one Anthropic model and one non-Anthropic model in your model list so a switch is a single click. Being able to move a blocked request sideways in seconds is what turns this error from a hard stop into a minor detour.
Reporting a False Positive to Anthropic via Cursor Support
When a block is clearly wrong and blocks real work, report it. Cursor collects these reports and relays the pattern to Anthropic, and enough reports on the same theme do change classifier behavior over time.
What to Include
Provide a reproducible, minimal description rather than a long narrative:
Model: Claude Sonnet (or Opus)
Task: reviewing a security patch for CVE-XXXX-YYYY
Prompt (summarized): explain the root cause and write a regression test
Context attached: two files, both sanitized, no secrets
Result: sensitive prompt error, request never reached the model
Reproduced on: 3 attempts in the same chat, 1 attempt in a fresh chat
Notes: same prompt succeeded on GPT and Gemini. This reads as a false
positive on a defensive security workflow.
Include the model name, the sanitized prompt, and the fact that it reproduces. Do not paste the raw sensitive content itself into the report; a description of the shape is enough and avoids re-triggering filters in the support tooling.
Where to Send It
Use the in-app support form or the published support address. Include the model name, the sanitized prompt, the reproduction steps, and a one-line description of the defensive purpose. Attach nothing raw. Even if support cannot reproduce the block, they can still forward the pattern to Anthropic, and recurring reports on the same theme are what eventually move the classifier.
A report with a stable reproduction and a clear defensive purpose is far more useful than a report that only says "the error keeps happening." Specificity is what makes the pattern actionable upstream.
Quick-Reference Troubleshooting Table
Use this table to move from symptom to fix without rereading the whole guide.
| Symptom | Likely cause | Fix |
|---|---|---|
| Error on first send, Anthropic model | Prompt or context tripped classifier | Rephrase, reframe intent, redact, or switch model |
| Works on GPT/Gemini but not Opus/Sonnet | Anthropic-only classifier | Switch to a non-Anthropic model |
| Chat stops mid-response then errors | Prior output now flagged in history | Start a fresh chat |
| Fails every turn in one thread | Poisoned conversation history | Start a new chat; do not retry in place |
| Fails after attaching a file | The attached content carries triggers | Reduce or sanitize attached context |
| Fails on large paste | Mixed signals from a big block | Split into smaller, focused requests |
| Fails on scan or exploit output | Reads as attack material | Summarize instead of pasting raw output |
| Intermittent, no clear trigger | Classifier edge behavior | Retry once, then switch model if it persists |
The pattern across all of these is the same: the classifier reads texture, so you win by changing the texture of what you send, by narrowing context, or by moving the request to a model that does not apply that classifier.
Treat the error as a signal about your context rather than a judgment about your work. Adjusting the shape of what you send keeps legitimate security, compliance, and analysis tasks moving while leaving the safety layer intact for the cases it was built to catch.
Keep a short note of the workarounds that resolved each block you hit. Over time that note becomes a personal playbook, and the next block clears in seconds instead of costing you a debugging session.