Configurable read-only shell access in Ask Mode

[Leland_Hepworth]

Feature request for product/service

Cursor IDE

Describe the request

Summary

Please bring back the ability to run read-only shell commands in Ask Mode, gated by the existing Allow List / Auto-Run settings, instead of the current all-or-nothing block. Ask Mode used to let read-only commands (like git log, git diff, git status) run through without issue when the OS sandbox wasn’t hard-enforcing a block. That’s now gone entirely, and there’s no in-between option: it’s either a shell-less Ask Mode or full Agent Mode with edit access.

Why it matters

I’ve relied on Ask Mode to ask the agent to run read-only git commands so it can investigate specific commits, working changes, or staged changes and base its answer on the actual command output rather than guessing. I use Allowlist (not Auto-Run-Everything) for command approval, and my allow list is already populated almost entirely with commands I’ve vetted as read-only. This setup worked well and I never had an agent attempt a non-read-only command in Ask Mode.

That changed recently, due to the following bug report post:

Ask Mode Terminal Commands

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug 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 looki…

The terminal in Ask Mode was never actually hard-blocked at the tool level — Ask Mode removed edit/apply and MCP tools, but write protection depended on a read-only OS sandbox that wasn’t always active. The user who posted that bug report hit that gap and got git add/git commit/git push executed from Ask Mode, although that should have still been gated by their allowlist or a prompt to run a command that required user approval. The fix that rolled out wasn’t a proper allowlist-aware guard. Instead it was a blanket block on the terminal entirely, as described in the follow-up thread:

Ask mode: agent unaware of shell restriction, doesn't suggest switching to Agent mode

Hello, I have been experiencing this same issue, apparently. I found this thread while trying to figure out why the agent wasn’t able to run shell commands successfully in Ask mode- it sounds like that’s a deliberate design decision, but I must have missed the memo there. The agent doesn’t seem to be entirely aware of that limitation either. It tried to run “psql” to query my PostgreSQL database, then when that failed twice, it tried running simpler shell commands three more times to resolve th…

That blanket fix took out my read-only git workflows along with the mutating commands it was meant to stop, and (per the same thread) the agent isn’t even aware of the new restriction: it silently fails, retries, tries to route around it via a subagent, and only mentions the block in its hidden thoughts instead of the main reply.

So the “fix” to that previous bug report removed functionality that many of us depended on, rather than tightening the block to cover only mutating commands. Now the only way to get shell output backing an Ask Mode answer is to switch to Agent Mode, which reopens file-edit and MCP access I specifically don’t want available for those tasks.

What I’d like

1. A read-only shell mode inside Ask Mode, enforced at the tool level (not solely dependent on the OS sandbox being active), that permits commands already present on the user’s Allow List and known to be read-only (e.g. git log, git diff, git status, git show, ls, cat, etc.), while still hard-blocking write commands (git add, git commit, git push, and similar) regardless of sandbox state.
2. If a full allowlist-driven model isn’t feasible short-term, at minimum a setting to toggle shell availability in Ask Mode for users who understand the tradeoff and already maintain a vetted, read-only-only Allow List.
3. If a shell command is blocked in Ask Mode, the agent should say so plainly in its main response (not just in hidden thoughts) and suggest switching to Agent Mode, rather than silently retrying or spinning up a subagent to work around the restriction.

Environment

• Ask Mode with Allowlist-based Auto-Run (not Auto-Run-Everything), allow list populated with vetted read-only commands
• Primary use case: grounding Ask Mode answers in real command output (git history/diff/status) without granting file-edit or MCP access

Operating System (if it applies)

Windows 10/11