Self-hosted workers developer workflows

I am loving self-hosted workers. I spin up a few workers manually worktrees on my local PC, and then I essentially use the cursor.com/agents to remotely interact with the self-hosted workers while I go for walks or am otherwise not at my PC. This is especially useful because I can’t currently use Glass or the agents window because my local repo is in a devcontainer, which isn’t supported. So this gives me a way to have an agents window on cursor.com/agents that’s even remotely accessible!

This works super well, but here are two annoyances:

  1. Don’t create a new branch! I have existing worktrees on feature branches already. I just want the agent to start working on the existing branch.
  2. Don’t always commit/push! Since it’s a self-hosted agent on my local PC, I like to open up the workspace in my IDE and manually review the code myself, and potentially commit/push myself.

The DX here would be better if you guys were less opinionated about the context automatically given to your “cloud agents”. I get that you’re pushing a particular workflow, but in my case I really am not interested in my agents auto-committing, auto-pushing, and opening PRs by themself.

Just my 2c!

Thanks,
James

Hey, thanks for the detailed feedback, it’s genuinely helpful.

Both items are on our radar. We already have an issue logged for the self-hosted local worker creating a new branch/PR without an explicit request. The auto-commit/push behavior is part of the same problem. The model is being too pushy with git operations in self-hosted setups, but for workflows with pre-made worktrees, that’s exactly what it shouldn’t do. I also reported your case as an extra signal.

I can’t share a timeline for the fix yet, but the direction is clear: less opinionated git behavior, more “just write the code, the user handles the rest”. I’ll try to follow up when we have updates.

Also, about devcontainer + Glass, the discussion is still going in this thread: Dev container remotes don't work with Glass. Worth subscribing if you haven’t already.

Bumping this - the git branch naming in particular is incredibly annoying and feels entirely counter productive. I am wasting tokens just telling models to use our git conventions as our git remote blocks branches not matching the target format.

Hey, thanks for the extra heads up, especially about the branch naming policy on the remote. That makes total sense, and burning tokens just to repeat model conventions shouldn’t be the norm.

Like I said above, the goal is to make self-hosted workers less opinionated about git, so the agent won’t touch branch, commit, or push unless you explicitly request it. I can’t share an ETA yet, but we’ll post updates in the thread as we have them.

As a temporary workaround, if you have .cursor/rules or AGENTS.md in the repo, you can hardcode the branch naming convention there. The model usually picks that up faster than chat instructions.