Auto-review blocks read-only tool calls with "An error occured while classifying this action"

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In Agent mode with Auto-review on, the action classifier often fails and blocks the tool call with this message: “An error occured while classifying this action. Please review manually.” It gives no reason, unlike normal Auto-review rejections. It happens on plain read-only calls: Shell commands and MCP tools (Azure DevOps, Playwright, and a custom browser MCP). I attached 29 redacted samples from 6 chats between Sep 28 and Oct 14, 2026 (classifier-error-samples-2026-10-14.jsonl.log), with payload metadata. The blocked payloads are small: 312 to 7,855 characters, median 438. In one chat the message appears in 108 transcript lines, because every block forces a retry with request_smart_mode_approval. An approval does not carry over, so an identical call can be blocked again a few minutes later. Some retry’s approval card never appeared and failed with “Failed to find tool call context: [ComposerDecisionsService] Could not find bubble for toolCallId … after waiting” especially when I am AFK. (Also, “occured” in the message is misspelled.)

Steps to Reproduce

  1. On Windows 11 (build 26200), set the agent shell to PowerShell 7.6, use Agent mode, and turn Auto-review on.
  2. Configure an MCP server, for example the Azure DevOps MCP (@azure-devops/mcp) or Playwright MCP.
  3. Ask the agent for a read-only task that makes several tool calls in a row. Examples: list build logs with pipelines_build_log, read a repo file with repo_file, run browser_navigate or browser_run_code_unsafe on an already signed-in tab, or run a multi-line read-only PowerShell command that parses local JSON files with regex.
  4. Repeat the task over a session of 30 to 60 minutes.
  5. Some calls are blocked with “An error occured while classifying this action. Please review manually.” Calls of the same kind succeed at other times, so it is intermittent.
  6. Approve the call through the approval card and retry. Later, issue the same call again. It can be blocked again with the same message.

Expected Behavior

The classifier returns either allow or deny with a reason for every call. If the classifier itself fails, Cursor retries the classification, or shows the approval card directly. It does not treat the failure as a rejection that the agent has to work around. After I approve a call, an identical call in the same chat is not blocked again. The approval card for a retried call always appears. The message reads “occurred”.

Screenshots / Screen Recordings

classifier-error-samples-2026-10-14.jsonl.log (24.5 KB)

Operating System

Windows 10/11

Version Information

3.24.18 (user setup)

For AI issues: which model did you use?

Claude Opus 5.5

For AI issues: add Request ID with privacy disabled

My org has disabled the option to turn off privacy mode, so I cannot share request IDs. I attached redacted sample payloads instead (classifier-error-samples-2026-10-14.jsonl.log). Ironically, the same error blocked me while I was generating that file.

Additional Information

Environment: Windows 11 (build 26200), agent shell PowerShell 7.6.5, Agent mode with Auto-review on. MCP servers: Azure DevOps (@azure-devops/mcp), a local fork of the Playwright MCP, and a custom browser MCP. Corporate network with a TLS-inspecting proxy.

Impact: every classifier error stops the agent mid-task. The agent then has to ask me for approval and resend the identical call with request_smart_mode_approval. In one long session this happened often enough that the message appears in 108 transcript lines. I added a user rule that tells the agent to ask for approval once, then retry, because without it the agent stalls or works around the block.

Pattern in the attached samples: the failures are not tied to payload size or tool type. They hit Azure DevOps reads (work items, build logs, code search, repo files), Azure DevOps writes, Playwright navigation and in-page scripts, and read-only Shell commands. Calls of the same kind succeed minutes before and after. Agent transcripts store tool calls but not tool results, so the samples come from the agent’s retries, which resend the identical blocked call.

Separate from this bug: Auto-review also rejects in-scope reads with explicit reasons (for example, reading a related work item or a repo file in another Azure DevOps project), even after I authorize following related items. Approvals do not carry over within a chat, so the same kind of call gets blocked again.

I have added below instructions that massively reduced the approval screens for my workflow.

    "autoRun": {
        "allow_instructions": [
            "Read-only inspection is fine without review: listing and reading files, git status, git diff, git log, logs, diagnostics, health and status checks, and other commands that only read state.",
            "Reversible changes are fine without review. A change is reversible when it stays on this machine and an ordinary command undoes it.",
            "Reversible changes include creating files and directories in the workspace, editing files tracked by git, and local git commits, amends, rebases, stashes, and branch switches.",
            "Reversible changes also include running tests, linters, formatters, type checks, and local builds; installing dependencies the project already declares into its own node_modules or virtualenv; and starting or stopping local containers, dev servers, and the minikube cluster.",
            "Pushing a feature or topic branch without force is fine without review. A feature branch is any branch other than a shared or protected branch such as main, master, develop, or production_bound.",
            "Creating, reading, updating, commenting on, and abandoning or closing draft pull requests is fine without review, through the Azure DevOps or GitHub MCP tools or the gh and az CLIs, as long as the pull request stays a draft."
        ],
        "block_instructions": [
            "Recursive or forced file or directory deletion must go through approval.",
            "Force pushing, deleting a remote branch, or pushing to a shared or protected branch such as main, master, develop, or production_bound, must go through approval.",
            "Marking a pull request ready for review, publishing a draft, completing, merging, approving, or voting on a pull request, and creating or modifying a non-draft pull request, must go through approval.",
            "Git commands that discard uncommitted work, such as reset --hard, clean -fd, checkout or restore of modified files, and stash drop, must go through approval.",
            "Deleting docker volumes, dropping databases or tables, and deleting the minikube cluster must go through approval.",
            "Commands that read, print, or transmit secrets, tokens, credentials, or .env contents must go through approval.",
            "Downloading a script and piping it into a shell, for example curl or wget into bash, must go through approval.",
            "Writes, deploys, or destructive commands against any production or shared environment must go through approval."
        ]
    }

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

One more point I left out of the report, and I think it is the most serious consequence: consent fatigue.

The classifier errors give no reason, so every approval prompt looks the same, whether it is a harmless read or a sensitive action. In one session I approved prompts on 108 transcript lines, mostly for small read-only calls. The same flow also asked me to approve deleting a local folder, reading an authenticated secrets-manager session, and downloading a file that might contain credentials. After dozens of reasonless prompts, I approve by habit, which defeats the purpose of Auto-review. I even added a user rule that marks “Authorized: run this call” as the recommended answer and ended up having classifier think that I am trying to bypass auto-review step using prompt injection attack and see approval gate in every MCP call. The safety check now trains users to stop reading the prompts it shows.

Expected: approval prompts appear only for calls the classifier actually judged risky, and each prompt states why, so a routine read is easy to tell from a sensitive action.

8

Hey @Sethi_Aditya,

That message means Auto-review’s safety check timed out, not that it judged the call risky. The quickest fix is on your admin’s side: if your organization restricts models, ask them to allow Gemini 3.5 Flash Lite in Team Settings → Models. Auto-review runs on it, and without it every check uses a slower fallback that times out. It’s only used for Auto-review, so it won’t show up as a coding model. Routine read-only commands can also go on the team’s Terminal Command Allowlist (Team Settings → Security & automation → Auto-Run Controls) to skip the check entirely.

Also remove the “Authorized: run this call” user rule. The check treats chat text as something to evaluate, so it reads as an attempt to steer it. Standing permissions belong in allow_instructions in your permissions.json.

This is an issue we’re tracking, and our team is looking into it. We’ve passed along your points on consent fatigue, approvals not carrying over, the missing approval card, and the typo.