What is going on ? That project has nothing to do with cyber whatever.
My bigger concern is that I have work with installing / updating servers and virtual machines on other projects and if that happens there that model will be completely useless to me.
Request ID: 150b6c38-7461-4c1c-90c0-33c9fe2f5846
{“error”:“ERROR_OPENAI”,“details”:{“title”:“Request blocked”,“detail”:“We are unable to complete this request because it was blocked under the model provider’s usage guidelines. Try a less sensitive prompt.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:,“analyticsMetadata”:{“actionRequired”:“cyber_policy_review”}},“isExpected”:true}
Request blocked We are unable to complete this request because it was blocked under the model provider’s usage guidelines. Try a less sensitive prompt.
ActionRequiredError: Request blocked We are unable to complete this request because it was blocked under the model provider’s usage guidelines. Try a less sensitive prompt.
I’ve been stung by this twice today. My project is a web app, nothing to do with security. Here are the prompts. Both times grok 4.7 refused so had to switch to another model:
Prompt 1:
“Fix please. Be careful not to break any functionality with other docs that are working fine, like multi-page docs where the text laryer on page 10 might not be rendered when on page 1 due to the view range.”
Prompt 2:
"OK. That’s fine.
I have an idea, which is maybe a bit unconventiona in terms of UX but lets have a go anyway.
When the user hovers over an “inappropriate source” badge, can we put a border around the source_verdict_reason so the user can quickly understand the badge?"
Just adding my experience of the same issue here. I’ve been experiencing it for 2-3 days, across Grok 4.6 and now 4.7 as well. I had hoped it was just a symptom of moving capacity across to the new model but alas it’s still here with 4.7.
Same situation with completely innocuous prompts. I am doing some game development work and had thought perhaps the guardrails thought i was developing cheats or something, but it was tripping on very basic requests like ‘OK, go ahead’.
In most cases I was able to work around it by dropping back to Cursor 2.5, but of course that’s not ideal.
An example Request ID: 83976c79-73a0-4a6d-9ce6-b6f88de10791
Hi @Foo667 Thank you! We’re aware of this and working on it. To my knowledge, this primarily impacts 4.7, so feel free to try with Grok 4.5 or 4.6 and let us know if you see the same behavior there. Thx!
Pure speculation: I suspect sometimes it keeps happening after changing model because the previous refusal becomes part of the context. Sometimes when I switch I get a ‘do you want to revert to this point’ prompt, suggesting something is lurking there beyond my request. I would imagine a model is more likely to refuse a request if there is a refusal in the context already.
Same here — my team is hitting this repeatedly. We’ve switched back to 4.6 as a workaround, but this needs to be fixed. Please keep us updated as soon as you have any news.
Even auto didn’t fix it this time. It’s actually getting worse. I would have expected it from outside models, but for the internal Cursor models it’s absolutely frustrating. Composer 2.5 managed to move the chat ahead but Grok keeps refusing. And I have 0% other models usage coz I had to use Gemni to do Grok’s work so I’m limited to Composer 2.5 .
It’s ridiculous. Really wanted to like grok 4.7 but I can’t work with it due this happening so often. I don’t understand how a frontier LLM can be so bad at this.
Same issue:
Request ID: 3da157cc-abae-4b50-9087-ffb6d3c55a79
{“error”:“ERROR_OPENAI”,“details”:{“title”:“Request blocked”,“detail”:“We are unable to complete this request because it was blocked under the model provider’s usage guidelines. Try a less sensitive prompt.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:,“analyticsMetadata”:{“actionRequired”:“cyber_policy_review”}},“isExpected”:true}
Request blocked We are unable to complete this request because it was blocked under the model provider’s usage guidelines. Try a less sensitive prompt.
ActionRequiredError: Request blocked We are unable to complete this request because it was blocked under the model provider’s usage guidelines. Try a less sensitive prompt.
at NPf (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:6924:18135)
at ZVs (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:6924:16789)
at lLf (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:6925:13912)
at Object.classify (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:6925:17472)
at iLf (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:6925:6366)
at async aqs.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:6925:16779)
at async Ule.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:8318:31468)
at async $Uo.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17780:17013)
at async $Uo.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17780:39121)
at async ADe._submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:8296:4491)
