Cursor CLI Agent mode appears enabled, but assistant remains stuck in Ask/read-only behaviour

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

In a chat that appears to be in Agent mode, the assistant repeatedly reports Ask/read-only restrictions and refuses to execute commands or make changes.

Environment / Machine Details

• Host: Lenovo IdeaPad L340-15IRH Gaming
• OS: Zorin OS 17.3 (Ubuntu Jammy base)
• Kernel: Linux 6.8.0-90-generic
• Architecture: x86_64
• CPU: Intel Core i7-9750H (6 cores / 12 threads, up to 4.5 GHz)
• RAM: 15 GiB (~6.3 GiB used at time of test)
• Swap: 19 GiB
• Shell: zsh 5.8.1
• Hostname: ideapad
• Workspace: /home/user/coding

User Impact

• Breaks real-time collaborative workflows.
• Forces copy/paste manual execution for each step.
• High friction in iterative tasks (in my case, live mic noise-suppression tuning).

Example Assistant Replies

• “I can’t execute changes myself in this current Ask mode…”
• “I still have an active Ask-mode restriction…”
• “I still have a read-only restriction in this thread…”

Frequency

• Reproduced multiple times in the same thread, including after explicit mode confirmation.

Workarounds Tried

• Explicitly telling assistant Agent mode is enabled.
• Asking it to continue in same thread.
• Issue persisted.

Suspected Cause

• Possible mode-state desync between frontend mode indicator and backend/session enforcement.

Steps to Reproduce

  1. Open a chat and perform Agent-style workflow (shell commands + iterative troubleshooting).
  2. Continue by asking assistant to execute additional commands.
  3. Assistant claims Ask/read-only restrictions and refuses execution.
  4. User explicitly confirms Agent mode is enabled and asks it to continue.
  5. Assistant still refuses, saying it is in Ask/read-only mode.

Expected Behavior

With Agent mode enabled, assistant should execute commands and make requested changes.

Actual Behavior

• Assistant remains read-only and only provides manual instructions.
• Repeatedly says it cannot run commands due to Ask-mode restrictions.

Operating System

Linux

Version Information

• Cursor CLI path: /home/user/.local/bin/cursor
• Cursor version: 2.4.32
• Cursor commit/hash: dac77182205e080f83e43f13ee42d822740a6e10
• Cursor arch: x64
• cursor-agent path: /home//.local/bin/cursor-agent
• cursor-agent version: 2026.03.11-6dfa30c

For AI issues: which model did you use?

Codex 5.3 extra high fast

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, this is a known issue. There can be a mismatch between the mode shown in the UI and what the model actually receives in the system prompt. The bug shows up in both the IDE and the CLI.

A working workaround is to always start a new chat in Agent mode, and don’t switch modes within the same chat. If you need to keep context, you can also try adding this to your prompt: You are in Agent mode. Execute commands directly. This sometimes helps switch the behavior back.

Related reports for context:

The team is aware of the issue. There’s no timeline yet, but each report helps with prioritization.

Let me know if the workaround doesn’t help.

6

Specifically telling it that ‘You are in agent mode’ - and to proceed, worked, but not the first time.

7

Glad the workaround helped, even if it didn’t work on the first try. If the “You are in agent mode” prompt doesn’t kick in right away, the most reliable option is to start a new chat in Agent mode from the start, instead of trying to switch modes inside an existing chat.

Let me know if it keeps happening even in fresh chats.

9

Hey @hadikhantech!

The CLI agent mode issue has been fixed in a recent Cursor update. Updating to the latest version should resolve this.