Where does the bug appear (feature/product)?
Cloud Agent (GitHub, Slack, Web, Linear)
Describe the Bug
Starting a Cloud Agent with a single repo + feature branch correctly uses that branch’s .cursor/environment.json (install / start). Starting with multiple repos (same primary repo + feature branch selected for it, plus a second repo) ignores the feature-branch selection and uses a different saved multi-repo environment/Build with default branches for both repos.
In this specific use case, I’ve made edits to the install and start scripts in a feature branch, that I wanted to test before we merge to main.
Steps to Reproduce
Launch a Cloud Agent with only Repo A on a feature branch that adds/changes .cursor/environment.json (install / start) vs default branch.
Confirm the feature-branch env is applied (e.g. tools installed only by that branch’s install).
Launch another agent selecting Repo A + Repo B.
Explicitly set Repo A to the same feature branch.
Check which environment/Build is used and which branch/commit each repo is on.
Expected Behavior
Multi-repo still checks out the selected feature branch for Repo A (and applies that branch’s env install/start as in the single-repo case), while also including Repo B.
Rather than just matching on “the user used these two repos, we have an existing environment for that, lets use it”, the expectation is “the user actually selected a specific branch for one of these repos, so I will not load the default environment in this case”.
Hey, thanks for the detailed report with screenshots and steps. That really helps.
Quick summary of what’s happening. On a multi-repo start, the per-repo branch picker controls which refs get checked out into the workspace, but it doesn’t control which install/start config gets applied. The Environment is a saved object tied to a set of repos, and its install/start comes from the saved config, which usually resolves from the default branch. So changes to .cursor/environment.json that live on a feature branch are currently only picked up on a single-repo start. The multi-repo branch picker won’t pull those in. The fact that your single-repo case worked, while multi-repo used the Environment from the default branch, matches this exactly.
The workaround you found is the right path for now:
Validate install/start script changes via a single-repo start, or
Merge the Environment changes into the default branch, or edit the Environment in the dashboard, then run multi-repo.
One quick clarification. You said both repos ended up on the default branches. Can you share the URL of that multi-repo agent run? I want to check whether the checkout of the selected branch didn’t happen, or if only install/start came from the saved Environment. Those are two different layers, and the URL will make it clearer.
I’ve shared the single-repo vs multi-repo behavior difference with the team. I can’t give a timeline yet, but I’ll follow up in the thread if there’s an update.
So basically I asked for main on one repo, and a feature branch on another. This run was started in the web UI, and my first question was what branches was active, and it responded with main on both, even though I chose a feature branch manually when opening the chat.
And, the reason being that an existing environment for that repo combination already exists, and it also has builds.
So it seems it then defaults to the both default branches for those repos, which is main and main.
Just to remind or my purpose with getting the feature branch was for the session to get changes in environment.json in a feature branch of a repo, to test new things before we merge, and at the same time have access to both repos.
Thanks for reproducing it and sharing the run link. That’s exactly what we needed to clarify.
There are two separate layers here. One is which install/start config gets applied. On multi-repo start, it’s taken from the saved Environment, and that’s the expected behavior right now. The other layer is the actual checkout of the selected branch in the workspace. What you’re describing, both repos ending up on main even though you explicitly picked a feature branch for one of them, is about the second layer. That’s not about install/start, it’s that the branch picker selection didn’t affect the checkout. That shouldn’t happen.
I’ve shared the run URL bc-f4c78b98-ae7e-43cc-8305-c2f336c28ff2 and your clarification with the team, specifically for this checkout layer. I can’t give a timeline yet, but I’ll reply in the thread if there’s an update.
One note for verification. Asking the agent “what branch am I on” is a decent signal, but sometimes it doesn’t reflect the actual git state. If you can, within the same run please execute git -C <path-repo-A> rev-parse --abbrev-ref HEAD and the same for the second repo. That will show exactly whether the checkout really stayed on main.
For now the workaround is still the same. Validate changes to .cursor/environment.json via a single-repo start, or merge the needed branch and run multi-repo. Let me know what git rev-parse shows.
