I’m using Cursor Cloud Agents via the browser (not the IDE).
My codebase is split across multiple GitHub repositories:
frontend
backend
mobile
specs / docs
I don’t use a monorepo.
When launching a Cloud Agent, I’m required to select a single repository.
Even though the Cursor GitHub OAuth app has access to all my repos, the agent can’t clone or access the others (e.g., via gh).
Questions:
Is multi-repo access intentionally unsupported for Cloud Agents today?
Are Git submodules expected to be the workaround here, or are they not officially supported?
Is there a recommended pattern for Cloud Agents when working across frontend + backend repos?
I can confirm that multi-repo support for Cloud Agents isn’t available today. It’s top of mind (it would be immensely helpful to us here at Cursor as well).
Submodules aren’t a great workaround here. Cloud Agents explicitly skip fetching submodule contents during setup (--recurse-submodules=no), and even if you (or the agent) manually initialized them, you wouldn’t be able to edit or make PRs to those repos.
Hey @Colin , do you guys have any update on multi repo support or timeline for it to be available? This will be unlock a lot of use cases for us, please let us know. I see posts from Nov 2025 already asking for such feature.
Hey Colin, would really love to hear if Cursor would commit to supporting this feature by end of year, month, or Q3. We’d love to see it as using complex syncing mechanisms is obviously not ideal.
Uses an environment variable that contains a GitHub personal access token PAT giving access to repos you want (can be read only, or even write depending on what you want the agent to do)
checkout the submodules, or even check them separately outside the main repo using the PAT
Depending on needs for what can happen after then setup script is finished (read only or update) you can also have the script configure a global git replace insteadOf rule that contains the said PAT so the agent can then freely pull, push, to any of the repos.
It’s a bit cumbersome to maintain, requires a long lived PAT, and please keep in mind that Cursor configured the main repo’s read/write token as another global git replace insteadOf rule but for the base github.com url so if you configure your own with different scopes and paths, make sure it doesn’t apply instead of cursor’s otherwise the agent might not be able to push to the main repo anymore. E.g. in my case, the main repo is from our org, and I want to give read access to all other repos within that same org, which means the orgXXX · GitHub path matches and replaces calls to the main repo GitHub.com/orgxxx/repoyyy which means I had to also copy cursor’s default replace rule to the longer more specific repo path.
I have successfully used this strategy for a repo with many submodules that are needed only in read access. It works fine, just took a bit of learning about git replace insteadOf configs.
This would be extremely useful. One half solution that will be instantly helpful is if I can trigger 2 cursor agents from the same message. One for each repository.
This way my workflow would evolve to:
Someone reports a bug to our #bug-tracking slack channel
I reply with @linear to create a ticket, assign to cursor and provide some specific instructions for backend and frontend repos.
Cursor raises the PRs using linear’s branch naming for both repos
I can review + implement changes + merge
Reason I think it’s a half solution is because both agents won’t be able to talk to each other in this setup. But its still better.
Another possible solution is to make environments support multiple repositories directly. That it fetches two repositories and runs it similar to having the cursor CLI on a machine with both these repos.
It’s the biggest blocker for me to use the cursor agents at the moment.
