Agentic Worktree feature is Dangerous

Hey, we just had some downtime in production due to the new agentic work tree Workflow.

When merging a worktree into the main repo that one of our developers is working on, the agent randomly decided to create a commit which deployed some extremely unfinished work to production.

The previous way WorkTree worked, where the merge was done deterministically, was safe.

You might claim that people should always work at a branch, but that’s simply not how people work in our company. It’s not going to be the way people work in the future. We’re constantly updating files and shipping commits straight to main, which deploys automatically. It’s a much faster way to work, and it’s the way that a lot of developers work both solo but also in teams when moving very quickly. Frankly, it’s gonna be the way that a lot of people work in the future.

In my view, the deterministic approach to worktrees was much better, faster, and more reliable. Seems like the only advantage of the agentic approach is that it automatically merges and handles conflicts, but this was not hard to do before.

At the very least, you should make sure that the worktree agents don’t create commits unless requested.

Hey, thanks for the feedback. That’s genuinely serious.

Your feedback about unwanted commits when merging a worktree is valid. A few other users have also reported unpredictable agent behavior when working with worktrees. The agent can go beyond scope and do things you didn’t ask for, including commits.

The team is aware of this and is reworking worktree support. For now, as a workaround, you can explicitly ask the agent in your prompt not to create commits without confirmation, or add a rule in .cursor/rules like Never create commits unless explicitly asked. It’s not perfect, but it helps reduce the risk.

Your feedback about going back to a deterministic merge is also really valuable, especially for workflows with auto-deploys to main.

Let me know if you have any other questions.

Cheers Dean