Good afternoon Cursor Team!
First of all, as always, I want to say thank you for an amazing product!
Today I want to raise the discussion about MCP in Ask mode or Custom Modes, which was discussed, for example, in this thread: Return the Custom Modes features
And I’d like to start with a real fatal issue that I ran into in this case.
So I had a long coding session (6+ hours) with a multi-subagent pipeline (planners, coders, reviewers, etc.) in one chat. And while the pipeline was actively running, I asked Agent in a parallel chat to review a coworker’s merge request using the GitLab MCP, so I had to give Agent mode to the MR-review agent.
And during the code-review process this agent decided to checkout the local branch for a more precise review. As you probably understand, this action completely killed the coding pipeline, because the code that appeared as a result of the git checkout was a very big surprise for the coding agents in the pipeline.
The final result was $300+ and a full workday thrown in the trash.
That is why I’d kindly ask to start a discussion about the possibility of reverting the Custom Modes feature, or any other way to make read-only MCP calls with write operations restricted at the working-mode level, not by LLM instruction.
p.s.
- Of course, I understand that there are several solutions to this problem — starting with hooks that prevent git operations for a custom MR-review skill, for example, and finally using git worktree for such operations. But these ways are more complicated and overkill for a quick daily routine. A simple toggle in Agent mode for an Ask+MCP mode would help here easily and effectively.
- I’ve also tried readonly subagents for review, but this strategy failed because a readonly subagent is equivalent to Ask mode and cannot run MCP requests, even read-only requests.
- As another strategy, we discussed in Cursor a variant of controlling subagents with a custom permissions.json. This approach seems good if we can separate common permissions from custom permissions for a specific subagent, but, as with the first point, it seems to be an overkill and over-complicated way.
Sounds super frusturating.
Sorry for not being clearer. No ETA at the moment.