Linear-triggered multi-repo agents — route via environment membership

Ideas Feature Requests
, , ,
1

Feature request for product/service

Background Agent (GitHub, Slack, Linear,…)

Describe the request

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
5

This is a really well-scoped request.

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.

7

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.

8

Same here, would be great to automate multi-repos work from a Linear-triggered agent!

9

Would also really love to have this feature. Especially when fixes might require changes to multiple micro-services.