I’ve been testing the interaction between Cursor’s shell hooks, autorun modes, and the command allowlist. One finding stood out:
Returning ask from a hook has no practical effect in either autorun mode:
In “Ask every time” mode, Cursor always asks – regardless of what the hook returns. So ask is redundant here.
In “Autorun in Sandbox” mode, Cursor always runs the command automatically – the ask return value is simply ignored.
The only hook return value that actually changes behavior is deny (blocks execution unconditionally) and allow (permits execution). The ask value appears to be a no-op in all tested configurations.
Test setup:
Hook return values tested: allow, ask, deny
Autorun modes tested: Ask every time, Autorun in Sandbox
Allowlist: tested with and without the command present
Command used: echo
Is this intended behavior? If so, the ask return value seems like dead code in the hook API. It would make more sense if ask triggered a prompt even in Autorun in Sandbox mode – giving hooks the ability to escalate specific commands to user confirmation.
Steps to Reproduce
see above
Expected Behavior
A hook returning “ask” should override other autorun behaviors
Hey, thanks for the detailed report and for testing this so thoroughly.
This is a known issue. The ask return value from hooks doesn’t work as expected in autorun modes. The team knows about it and it’s on their radar, but there’s no ETA for a fix yet. Your report helps us prioritize it.
You’re right that ask should override autorun and force a confirmation prompt, especially in “Autorun in Sandbox” mode. Right now, only deny and allow have a real effect.
As a workaround, you can use deny with a user_message to block commands that need human review. That at least gives you a gating option, even if it’s not as smooth as a proper ask flow.
Let me know if you have any other questions about hooks.
I want to explicitly highlight that, from my perspective, this behavior is highly problematic.
If a hook returns ask, but this return value has no practical effect in relevant execution modes, then the documented control surface does not match the actual runtime behavior. For a feature that is directly related to controlling tool execution, this is not a minor inconsistency — it fundamentally undermines trust in the safety model.
Unfortunately, this issue does not appear to be isolated. There are other examples where fine-grained control over tool execution behaves inconsistently. One example is that MCP server allowlists are applied even in “Ask Every Time” mode, which can lead to tools being executed despite an explicit user decision to skip them. This again weakens the mental model of “explicit user confirmation equals no execution.”
Taken together, these patterns create the impression that users are currently not given reliable, fine-grained control over what the system is allowed to execute and under which conditions. For teams that evaluate Cursor not just as a productivity tool but as software operating within a security-sensitive environment, this is a critical concern.
What adds to the uncertainty is the perceived prioritization. Several of these issues have been reported for some time. From the outside, it can appear as if security-relevant inconsistencies are acknowledged but not addressed with the urgency one would expect, while feature development continues at high speed. I fully understand the pressure to innovate, but control and predictability in tool execution should be foundational.
At this point, I am seriously questioning whether we can continue recommending Cursor in environments where strong guarantees about tool execution and safety controls are required. Trust in the vendor’s prioritization of security is a key factor for us.
I hope this feedback is taken in the constructive spirit intended: reliable, well-documented, and actually enforced execution controls are essential for long-term adoption in professional and security-conscious settings.