Agents Window Git actions: Commit button is opaque and uncontrollable

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:

  1. 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.

  2. 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.

Hey @boke0, thanks for the detailed feedback.

A couple of things that may help right now. The Commit button in the Agents Window reflects what is staged: if you stage the files you want in the Changes tab first, the agent commits exactly that set and nothing else. It only chooses the set itself when nothing is staged, which is where the “left these files out” behavior comes from.

You can also type /commit (or /commit-and-push) in the agent input and add instructions after it, for example “/commit include every modified file”. Commands you define in .cursor/commands show up in the same / menu, so a command like /my-commit can carry your own staging and commit rules.

Making the Git buttons themselves less opaque is something the team has been looking at!

Thanks for the reply — that helps.

I’ll try staging in the Changes tab first for now. That said, if I already need to open Changes to stage, it’s usually easier to just use the Git buttons there. So for the Agents Window Commit button, I’d still prefer a flow that doesn’t depend on Changes-tab staging — something whose staging policy is explicit (or user-owned via a slash command / configurable prompts), rather than “stage elsewhere first, then press Commit here.”