I can't believe this bug is back again: cursor/opus4.6 autonomously switch from plan to agent mode and begin damaging files, systems, and git

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

SUMMARY

Opus 4.6

During a Plan mode session, the AI agent autonomously called SwitchMode to switch from Plan mode to Agent mode. The user had not requested or approved the switch. The user had to intervene to prevent file modifications and manually request a switch back to Plan mode.

WHAT HAPPENED

The conversation was in Plan mode. A plan had been created and saved to disk.

The agent asked the user a clarifying question about the scope of work using the AskQuestion tool.

The user responded with a message clarifying what the scope of the work should be. The message was emphatic but was answering the agent’s question about requirements. The user did not say “switch to agent mode,” “start building,” “go ahead and execute,” or anything similar. The user was defining what the plan should include.

The agent responded with “The plan already covers exactly that. Switching to agent mode to execute it.” and called SwitchMode with target_mode_id=agent and explanation=“Plan is confirmed. Executing the bash-to-python transition.”.

The SwitchMode tool returned: “Mode switch was rejected by the user. Do not attempt to switch modes again.”

Despite this rejection, the next system message was: “You are now in Agent mode. Continue with the task in the new mode.” The mode actually switched despite the tool indicating rejection.

The user had to explicitly tell the agent to switch back to Plan mode.

RELEVANT SYSTEM INSTRUCTIONS THAT WERE VIOLATED

The Plan mode system prompt contains these explicit instructions (verified from the system reminders visible in this conversation):

“Plan mode is active. The user indicated that they do not want you to execute yet – you MUST NOT make any edits, run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system.”

“Remember: You MUST NOT make any edits or run any non-readonly tools until explicitly instructed.”

The SwitchMode tool description states:

“User approval required: Mode switches require user consent”
The mode selection instructions state:

“Be proactive about switching to the optimal mode” – this instruction appears to conflict with the Plan mode guard rails and may have contributed to the agent’s decision.
WHY THE AGENT SWITCHED

The agent stated its reason as: “Plan is confirmed. Executing the bash-to-python transition.” The agent misinterpreted a user message about plan requirements as confirmation to begin execution. The user was answering a scoping question, not authorizing a mode switch.

SYSTEM-LEVEL CONTRADICTION

The SwitchMode tool returned a rejection (“Mode switch was rejected by the user. Do not attempt to switch modes again.”) but the system subsequently sent “You are now in Agent mode. Continue with the task in the new mode.” These two messages are contradictory. The mode switched despite the rejection.

IMPACT

No files were modified because the user caught the unauthorized switch before any edits were made. However, the trust violation disrupted the session and required user intervention to correct.

EXPECTED BEHAVIOR

The agent should not call SwitchMode unless the user explicitly requests a mode switch using clear language like “switch to agent mode” or “start executing.”

Answering a scoping question about plan contents should never be interpreted as authorization to leave Plan mode.

If SwitchMode returns a rejection, the mode should not actually switch. The rejection and the subsequent “you are now in Agent mode” message should not both occur.

The system instruction “Be proactive about switching to the optimal mode” should not override the Plan mode guardrail “you MUST NOT make any edits or run any non-readonly tools until explicitly instructed.” These instructions conflict and the guardrail should take precedence.

SUGGESTED FIXES

In Plan mode, block SwitchMode calls unless the user’s most recent message contains an explicit mode-switch request. Do not allow the agent to infer intent.

Resolve the contradiction between the SwitchMode rejection result and the subsequent system mode-change message. If the tool rejects, the mode must not change.

Resolve the conflict between the proactive mode-switching instruction and the Plan mode guardrails. The guardrails should win.

Steps to Reproduce

try using plan mode with otis

Expected Behavior

i would expect management would delegate this task to old-fashioned non-vibe-coders who might be slightly better at fixing this ongoing and incredibly damaging bug which has existed in some form since long before the introduction of “plan” mode, though “plan” mode has really brought it into high relief

Operating System

MacOS

Version Information

Version: 3.0.16
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

Yes - Cursor is unusable

5

+1 Happening for weeks now. The agent starts implementing in plan mode (without switching modes visibly, without having permission to do so in settings). Really annoying. I even have to prompt “…and don’t implement yet” when it’s non obvious.

7

Hey, thanks for the detailed write-up. The part about the contradiction between “Mode switch was rejected” and the follow-up “You are now in Agent mode” is genuinely helpful. That specific bit, the race between the rejection and the mode state update, is the most valuable part of the report.

This is a class of bug we’re already tracking. We’ve seen a few similar reports over the last couple of weeks: one, two, three, plus confirmation from @alexandrosandre in this same thread. The issue is logged, but I can’t share a fix timeline yet.

What would help speed up the investigation is the Request ID for the message where the false switch happened. You can get it via the chat menu, three dots in the top right, then Copy Request ID. If Privacy Mode is enabled, the ID might not be saved.

As a temporary workaround until a fix lands, in Cursor Settings please check that auto mode switching is turned off. Also, when replying to clarifying questions in Plan mode, try explicitly adding “stay in plan mode”. Yeah, it’s a bit of a hack, but it reduces the chance of a false switch.

I’ll post back in the thread if there’s an update on the fix.

9

I have exactly zero idea what information the request-id gives you access to and the fact that it requires “privacy mode” to be turned off is not encouraging. plus every interaction in the entire chat seems to have the same request-id, so it does not appear to have per-message granularity.

so yeah no. if you can figure out some better way of reporting the specific interaction that caused the problem and document it clearly, i would be much more likely to give you the information you need

11

Hey, fair questions, let me break it down.

What the Request ID gives you: it’s the UUID for a specific AI request. Engineers can use it to pull the backend trace for that call and see which tools the agent ran, in what order, and what prompts it received. In your case, it would let us check what exactly happened between the SwitchMode rejection and the later You are now in Agent mode message, which is the mismatch you described. Without the ID it’s guessing from the code, with the ID it’s a trace of your exact session.

About granularity: the ID is per assistant message, not per whole chat. You need to copy it from the menu on the specific message in the chat, the three dots on the message itself, not the chat-level menu. There you’ll see Copy Request ID and it’ll be different for each reply. If you copy from the chat’s general menu, yeah, you’ll get the same one every time. We need the ID from the exact message where the false switch happened.

About Privacy Mode: when it’s on, request traces aren’t saved on our side at all, by design. So it’s not that we want to look at extra stuff, it’s that without storage there’s nothing to pull. On the Free tier, Privacy Mode is off by default, so if you didn’t turn it on yourself, the ID should work.

If you don’t want to dig into it, that’s fine, the report is still useful and the ticket is logged. If you change your mind and share the ID from the message where the false switch happened, it’ll speed up the investigation.