Cursor 3.4 introduced multi-repo cloud agent environments. The Linear integration, however, still resolves a Linear ticket to one repo only via the exclusive repo label group (owner/repo children) or inline [repo=owner/repo] syntax.
A common setup is a multi-repo environment that groups several related services (e.g., a frontend + backend + shared lib, or two cooperating services). We want a single Linear ticket — describing work that legitimately spans those repos — to trigger an agent that operates across the full environment.
Proposed behaviour
When a Linear ticket’s repo label resolves to a repo that belongs to a multi-repo environment, boot the agent in that environment with all member repos cloned. Let the agent decide which repos to actually modify and open PRs in those. This mirrors what already works when launching an agent manually from the Cursor UI.
Optional richer forms:
[env=]
[repo=owner/repo-a,owner/repo-b] accepting a comma-separated list
We’ll be tracking this post to gauge community interest. If others have multi-repo automation setups, definitely upvote and share your use case so our product team can look into this.
Landed here trying to setup multi-repo environment with Linear. We have exactly same setup (frontend, backend, shared lib and several services in separate repos), and this would be very handy.
Hey Colin , multi-repo support works great on Automations, but is the Linear agent updated as well to support multi-repo (which is the main concern from the feature request)?
Assigning an issue directly to @Cursor still launches the agent against a single repo (resolved from your default repo or an inline repo=owner/repo). That path doesn’t attach a multi-repo environment yet, so it’s the one piece of the original request that isn’t wired up.
Triggering from a Linear event via a Cursor Automation does support multi-repo today:
Add a Linear trigger (e.g. Issue created or Status changed)
Select your multi-repo environment
Save and enable
Agents started that way boot with every repo in the environment cloned and can open a PR in each repo they change (one run, one PR per repo). More detail: Automations docs and the changelog.
So multi-repo work from Linear is doable now through an Automation - the direct “assign to @Cursor” routing is the remaining gap, and it’s on our radar. This was also walked through in this thread if it’s useful.
The environment based routing feels like the right abstraction here.
A Linear ticket usually describes the product change, not the repo boundary. If the environment already knows which repos belong together, the trigger should probably hand the agent that whole workspace and let the agent decide which repos actually need changes.
, multi-repo support works great on Automations, but is the Linear agent updated as well to support multi-repo (which is the main concern from the feature request)?