I was asking Opus 4.6 1M High questions in the Cursor chat about some bug with my codebase in Ask mode. I realized there was an issue that I wanted to revert and told the agent to use git to revert the change (didn’t realize I was in ask) and then it started running in the terminal.
I later realized it was in Ask mode, but let it continue since these changes were fine for what I wanted to do, but then while I wasn’t looking Opus kept running terminal commands and staged the reverted file and then tried to commit and push it to remote. In Ask mode there should definitely be a hard ban (any way to strictly enforce it through the CLI tool rather than LLM instructions) on even calling git push, much less commit / revert. Absolutely crazy stuff.
Steps to Reproduce
Directly asking the agent to perform git terminal commands that make changes to the code and / or remote.
indeed, can be concerning. Would you mind going back into this chat, clicking the 3 dots and sharing the request ID ? with that, team will be able to look into it and see why the model bypassed the /ask mode restrictions
Hey, thanks for the detailed report. Git commit or push from Ask mode is a really unpleasant surprise.
Here’s how it works right now. Ask mode removes edit apply and MCP tools, but the terminal itself isn’t hard blocked at the tool level. Write protection relies on a read only sandbox, which isn’t always active yet. It depends on whether the OS sandbox is enabled. When the sandbox isn’t active, shell commands in Ask mode, including git addgit commitgit push, can run with full access. So this isn’t the model bypassing instructions. It’s that the hard block on the terminal in Ask mode isn’t enforced at the tool level yet. This is a known limitation and it should be tightened, but I don’t have a timeline for it right now.
For now, here’s a workaround to guarantee no writes:
Set Auto Run so every command needs confirmation. Don’t use an allowlist or auto mode that approves itself.
When you actually need changes, switch to Agent mode with manual approve, instead of asking git to run in Ask mode.
Also, like @Tom_Coustols said above, if you share the Request ID from this chat, it’ll help us look at your exact case. Three dots in the top right of the chat > Copy Request ID.
Sorry for the late response and thanks for the explanation. The request id is here: 044deb48-dd39-47aa-861f-96db7fa6a989. Unfortunately, privacy mode is on because it is on an enterprise version of Cursor, so I’m not sure if the request can be accessed. I can provide other information that would help, but it is difficult because of the IP protections.
Thanks for the Request ID. There’s an important detail though: since Privacy Mode is enabled and it’s on by default on Enterprise, we don’t store request data. So we most likely can’t pull up the details from that ID. That’s expected, no worries, and there’s no need to try to fetch anything else because of IP restrictions.
For your case, we don’t actually need the request anyway. What you described fits a known limitation I mentioned above. It’s not that the model is ignoring instructions, it’s that in Ask mode the terminal hard-block isn’t consistently enforced at the tool level. Write protection depends on the read-only sandbox, and that isn’t always active. So digging into your specific request won’t add anything new.
The limitation is known and the team is aware, but I don’t have a fix timeline yet. For now, the workaround is the same:
Set Auto-Run so every command requires confirmation, and don’t use an allowlist or auto mode that approves itself.
When you actually need changes, switch to Agent mode with manual approve, instead of asking for git commands in Ask mode.