Cursor IDE Agent chat mode enforcement

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent chat: Ask-mode write blocks after Implement despite Agent mode (mode desync)

Failure: Tool writes (Write / TodoWrite / Shell mutate) are rejected with Ask-mode policy text while the owner has selected or been told the chat is in Agent mode and has issued an explicit Implement / continue instruction after plan approval.

How we tested (evidence for the forum)

Approved a CreatePlan (Critical nested dogfood RCA) and clicked/issued Implement with instruction not to edit the plan file and to complete todos.

System reminder / UI indicated Agent mode at least once during the implement path.

Agent attempted Write to private journal and User-rule updates → hard fail: You are in ask mode and cannot run non read-only tools. Ask the user to switch to agent mode if edits are required.

Owner switched / re-confirmed Agent and sent Please continue → writes then succeeded (journal + User rules + docs).

Side observation: even when Agent stuck, mode can flip mid-thread without owner action, producing false confidence that Implement is allowed.Cursor Agent chat sometimes enforces Ask-mode tool policy (blocking Write/Shell/TodoWrite) even when the conversation is labeled Agent and the user has approved a plan and issued Implement / continue.

Symptom: tool results return exactly:
“You are in ask mode and cannot run non read-only tools. Ask the user to switch to agent mode if edits are required.”

This happens mid-execute on an approved plan, so Agent cannot land the work the owner just authorized. Switching mode again and sending “continue” eventually unblocked writes — which shows a desync between UI/session mode and the tool policy gate, not a user misunderstanding of Ask vs Agent.

Steps to Reproduce

  1. Open Cursor IDE (Windows Stable). Version: 3.12.30 (user setup), commit 63a2996a10d9e476b6c28e951dd7691d9c0cf480, 2026-07-21 build.
  2. In Agent chat, complete a CreatePlan / plan approval for a non-trivial implement (writes required).
  3. Start Implement (or equivalent “implement the plan” / Build) with the chat believed to be in Agent mode.
  4. Observe the agent attempt a Write (or other mutate tool).
  5. Note tool rejection with Ask-mode wording even though Agent was selected / previously active.
  6. Switch chat to Agent (or re-toggle) and send “continue” — writes then succeed.

Repro is intermittent but observed on 2026-07-23 during an approved plan Implement on Windows 10.0.26300, AI Model: Auto.

Expected Behavior

When the chat mode is Agent (or Implement/Build has been authorized in Agent), mutate tools must be allowed. Ask-mode policy must apply only when the chat is actually in Ask mode. UI mode label, system mode reminder, and tool policy gate must stay consistent for the same turn.

Operating System

Windows 10/11

Version Information

Version: 3.12.30 (user setup)
VS Code Extension API: 1.128.0
Commit: 63a2996a10d9e476b6c28e951dd7691d9c0cf480
Date: 2026-07-21T22:50:03.568Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26300

For AI issues: which model did you use?

Model: Auto

Additional Information

TX fix request for Cursor engineering / agents:

  1. Single source of truth for chat mode per turn: UI mode, system reminder, and tool policy must read the same enum (Ask vs Agent). Rejecting writes with Ask text while the turn is Agent is a P0 trust break for Implement.

  2. On Implement / Build / “continue after approve,” assert Agent policy before the first mutate tool call. If mode is Ask, fail closed with an owner-visible mode picker — do not silently apply Ask policy under an Agent label.

  3. Add a diagnostics line in the Ask-block error: currentMode=<ask|agent> source=<ui|session|reminder> turnId=… so reports are actionable.

  4. Regression test: approve plan → Implement in Agent → Write must succeed; same sequence forced Ask → Write must fail with Ask text and UI showing Ask.

  5. Do not weaken security gates; fix consistency only. No ask to disable failClosed hooks or skip verify.

Environment (auto-attached on form): Windows_NT x64 10.0.26300; Electron 40.10.3; Chromium 144.0.7559.236; Node 24.15.0; VS Code Extension API 1.128.0; Stable.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hi @J_T1 Thank you for the post! I tried to reproduce this on windows but I wasn’t able to. By any chance can you include a screenshot or a quick screenshare of the error? This will help me file the bug report with this.

7

@kevinn Thanks — happy to help. I can’t force a repro on demand (it’s intermittent after Cursor shell-exec host fails before the hook runs), but here’s the exact failure surface when it hits:

Error (agent Shell / fail-closed):
Tool blocked because this hook is configured to fail closed (block when it fails).
Hook “pwsh.exe -NoProfile -ExecutionPolicy Bypass -File .cursor/hooks/block-dangerous-git.ps1”
execution failed: Error: MainThreadShellExec not initialized

Environment:

  • Windows 10/11 (build 26300 class)
  • Cursor agent Shell invoking a git-shaped command
  • Repo has .cursor/hooks.json with failClosed: true
  • Hook script: .cursor/hooks/block-dangerous-git.ps1

Notes for the bug:

  • Failure is in Cursor’s MainThreadShellExec host before PowerShell hook logic runs
  • Owner terminal / pwsh -File outside agent Shell is fine
  • Reload Window sometimes clears it; not always immediately reproducible