I’ve been using Git actions in the Cursor Agents Window, and the click behavior feels wrong.
When I press Commit, some files get staged by a policy I cannot see, and the agent then commits “whatever happens to be staged.” I never chose that set of files. Commit is a single button — I can only press it. There is almost no way in settings to control what that press actually does. For a one-button interface, that is extremely inconvenient.
I have repeatedly thought a commit went through, then later noticed the agent had written something like “I deliberately left these files out of the commit” and shipped a partial commit. That is easy to miss, and it has bitten me many times.
In IDE / Editor mode this did not happen, because Git was a real GUI: I could see the file list, stage what I wanted, and commit that.
If the current design is “ask an agent to commit,” it would be more reliable to type “commit this” in the chat, or to run a slash command I define. Those at least make the policy explicit. At the same time, a one-click Commit button is hard to give up. Cursor’s GUI is supposed to make this kind of action easy to reach.
I would like one of these two directions:
-
Make the Commit prompts configurable. From the chat, it looks like Commit is several AI steps, not a single
git commit. I cannot tell which parts the model owns. I want to tune a prompt at each AI-owned step — staging policy, commit rules, and so on — so the button’s behavior is something I can actually set. -
Stop treating Git Action buttons as a hidden agent workflow. Make them shortcuts to slash commands instead, so a user-defined git command is still one click, but I own the command.
Either way, a Commit button should not invent a staging set I did not ask for, then quietly omit files and still report success.