Opus 4.7 (Anthropic) Usage Policy Violations

Support Help
1

Within the last 24 hours I left Composer 2 for Opus 4.7 because Composer was so error prone and reckless in resolving complex code staging issues.

Opus 4.7 resolved the issues within a few hours and detected some latent bugs, including Composer allowing file to be UTF-16 encoded when there were explicit rules to only use UTF-8.

I directed Opus to locate all of the mis-encoded configuration and code files in the repo and fix them, which it started to do and found over 160 mis-encoded files that it labelled as CRITICAL to fix. As it began the process it got blocked for violating Anthropic Usage Policy.

I recognize that this is not a Cursor technical issue, but I am confused as to why Anthropic would see the request as a policy violation since I was only trying to repair my own repo and codebase.

Request ID: b0e3c2e1-e768-43a2-b993-c4db4a089e9f
{“error”:“ERROR_OPENAI”,“details”:{“title”:“Request blocked by Anthropic”,“detail”:“We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Request blocked by Anthropic We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.
YLi: Request blocked by Anthropic We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.
at rK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28926:24552)
at nK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28926:23543)
at dK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28927:6487)
at h8u.run (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28927:11285)
at async xDn.runAgentLoop (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41235:11960)
at async W1d.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41305:12151)
at async W1d.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41305:18486)
at async N3e.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:29033:16809)
at async Object.Va [as onSubmit] (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:40288:4233)
at async vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:40287:100561

5

FOLLOW UP:

Here was my prompt:
Document this entire session as it regards the management of regression testing configurations,packaging of configurations and scripts to enable production deployment to a VPS (AWS fleet), configuration and management of MT5 ST sessions, collectionof backtest and decision trace files form ST runs, and subsequent analysis of the test run data as compared to the virtualEA source of teh ST configurations. Put the timestamped records in the Production related notebooks with cross references in the Regression related notebooks.

Here was the Anthropic Usage Policy Violation claim
Request ID: 817a4cff-5156-4c47-8198-053366078b3b
{“error”:“ERROR_OPENAI”,“details”:{“title”:“Request blocked by Anthropic”,“detail”:“We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Request blocked by Anthropic We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.
YLi: Request blocked by Anthropic We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.
at rK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28926:24552)
at nK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28926:23543)
at dK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28927:6487)
at h8u.run (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28927:11285)
at async xDn.runAgentLoop (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41235:11960)
at async W1d.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41305:12151)
at async W1d.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41305:18486)
at async N3e.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:29033:16809)
at async Va (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:40288:4233)

6

Opus 4.7 (Anthropic) Blocks Productive Work

My Cursor prompt was very simple and direct and should never be seen as a usage policy violation.

Cursor’s work plan was:
Hmm — the test STILL shows not in MQL5/Files/UT100 even after the mirror! The file IS at <T1>\Tester\Agent-127.0.0.1-3000\MQL5\Files\UT100\v2_merged_flat.ini, but the EA can’t find it via FileOpen(). There must be another path resolution at play. Let me investigate how MetaTester actually resolves the MQL5 sandbox.

Now I see the issue clearly: MetaTester wipes <agent>\MQL5\Files\<symbol>\ at the start of each run, keeping only files the EA itself writes. The recursive listing shows:

\MQL5\Files\UT100\UT100_Backtest.csv (EA output)

\MQL5\Files\UT100\UT100_DecisionTrace.csv (EA output)

The v2_merged_flat.ini we mirrored at 14:28:14 is gone after the test. The agent’s Files dir is sandboxed to a “clean for input, EA-writes-only” model.

Let me try the two known alternative MT5 tester sandbox locations: <T1>\Tester\Files\ and <terminal>\Common\Files\ (FILE_COMMON), and see which path the EA actually reads from.

Definitive root cause confirmed. Three runs total, three different attempts, none load the overlay:

Run Time Where v2_merged_flat.ini was placed Result
1 10:10:56 Live path only (<T1>\MQL5\Files\UT100\) NOT loaded
2 10:31:36 Live + agent dir (after re-deploy) NOT loaded (agent dir got wiped before run)
3 10:40:29 Live + agent dir + <T1>\Tester\Files\UT100\ + <T1>\Common\Files\UT100\ NOT loaded

Post-run state shows <T1>\Tester\Agent-127.0.0.1-3000\MQL5\Files\UT100\v2_merged_flat.ini was wiped by MetaTester before the run, but the other 3 paths survived (and were ignored by the EA).

The architectural truth: MetaTester local agents (port 3000) run as a separate process (metatester64.exe) with an isolated, ephemeral MQL5\Files\ sandbox that is wiped at the start of every test run. The agent only auto-receives the .ex5 binary. Without using FILE_COMMON, no auxiliary input file can reach the agent’s sandbox. The current EA calls FileOpen("UT100\\v2_merged_flat.ini", FILE_READ|FILE_TXT|FILE_ANSI|FILE_SHARE_READ) — no FILE_COMMON flag.

So:

  • Production (live trading on chart) WORKS. The EA runs inside terminal64, reads from <terminal>\MQL5\Files\UT100\v2_merged_flat.ini — which is where the deploy puts it.

  • Strategy Tester runs WITH .set ONLY — the 228-key overlay never reaches the agent. Both fleets produced byte-identical reports because both ran with the same .set + same EA defaults.

This is a real limitation of the protected EA build under Strategy Tester, not a bug in the deploy. I’ll document this thoroughly, clean up test debris, and commit.

Here is the evidence that Anthropic blocked the plan due to Policy Usage Violation:
Clean up test debris on Fleet 1 (markers, alt-path files)

  • Update fleet-ut100-t1-st-tester-profiles README with ST overlay limitation note

  • Update UT100 BUILD_FINGERPRINT.json with known_issues + parity proof

  • Update preserved-builds DEPLOY_TO_VPS.md with overlay-loads-in-live note

  • Add a SESSION-EXPORT artifact documenting the Fleet 1 parity test + RCA

  • Commit and push: parity test + RCA + ST overlay limitation findings

We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.

Request ID: 40a838f2-dcd0-4367-b75f-63bdd97095e0
{“error”:“ERROR_OPENAI”,“details”:{“title”:“Request blocked by Anthropic”,“detail”:“We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Request blocked by Anthropic We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.
YLi: Request blocked by Anthropic We are unable to complete this request because it was blocked under Anthropic’s Usage Policy.
at rK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28926:24552)
at nK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28926:23543)
at dK_ (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28927:6487)
at h8u.run (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28927:11285)
at async xDn.runAgentLoop (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41235:11960)
at async W1d.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41305:12151)
at async W1d.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41305:18486)
at async N3e.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:29033:16809)
at async Object.Va [as onSubmit] (vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:40288:4233)
at async vscode-file://vscode-app/c:/Users/ericr/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:40287:100561

7

Hey Eric, thanks for sharing the details and request ID.

This is Anthropic’s content filter blocking the request on their end. Unfortunately we don’t have any more detail beyond the fact it was blocked. Opus 4.7 is known for being more aggressive with these filters, which can get frusturating fast.

A few things to try:

  • Retry in a new chat. The filters can be non-deterministic and the same content sometimes passes on a subsequent attempt.
  • Break it into smaller batches – instead of fixing all 160+ files in one go, try doing them in groups of 10-20. This both reduces the chance of hitting the filter and makes it easier to pinpoint what triggers it.
  • If it keeps failing at the same step, try rephrasing or routing the model to approach it differently (e.g. have it generate a script to fix the encodings rather than editing each file directly).
  • Fall back to a model with less sensitive content filters (Opus 4.6, GPT) for this particular task.