Problem: When delegating Linear issues to @Cursor, repo routing works via repo/ labels, but worker pool must be selected manually every time — even when the repo implies the pool (e.g. repo/redzone-ios-code → macOS/Xcode pool).
Expected/Desired: Repo→pool mapping configurable at team or repo level (dashboard setting, .cursor/environment.json, or infer pool when only one pool serves that repo).
Workaround today: Linear pool/ label group + triage rules to auto-apply pool label alongside repo label. Works, but it’s duplicate config and poorly documented on the Linear integration page.
Use case: Multi-repo org with platform-specific self-hosted pool (iOS/macOS, Android, etc.). Assigning repo + pool on every ticket is friction that shouldn’t exist.
The case you’re describing should mostly just work today under one specific combination: if each repo maps to only one pool, and your team has “Require Self-Hosted Pool” turned on for all cloud agents. In that setup the repo label alone is enough to land a ticket on the right machines, you shouldn’t need to pick a pool at all.
On our side, worker-pool labels on a Linear issue aren’t actually read for routing (only repo, branch, and model are) — so a triage rule stamping a pool/ label shouldn’t be doing anything. Which makes me want to understand what’s really carrying the routing for you:
Do you have Require Self-Hosted Pool enabled, or are you opting in some other way (e.g. typing pool=/self_hosted= in the ticket)?
If you removed the pool/ label / triage rule entirely, do jobs still land on the right machines, or do they fall back to Cursor-managed?
Is each of your repos served by exactly one pool, or do some repos have machines in multiple pools?
To answer your questions: No, Require Self-Hosted Pool is turned off. We only need one repo routed to a particular pool; most repos can run on the default Cursor-managed cloud. So no, it’s not a case where each repo is served by exactly one pool, but there is one repo that is served by exactly one pool (or rather will be).
I reached out to Support about this last month, and they told me that this was an intentional security-related design decision. Here’s an excerpt of what I wrote then:
What we’re trying to accomplish is the following workflow:
Within Linear, an issue is assigned to Cursor
Given some context within the Linear issue (labels or in the description; we’re flexible on this point), the Cursor agent will complete the work described in the Linear issue in a self-hosted macOS worker/pool, and then open a PR.
I was able to get Cursor to route the running of the agent to the self-hosted by commenting on the Linear issue with “worker={workername}” and “pool={poolname}”, but it didn’t work when I assigned the Linear issue to Cursor.
Here’s an excerpt of the support response:
I checked internally and what Linear described is accurate, pool= / worker= directives are only read from the triggering @Cursor comment, not from the issue description or labels. This is intentional and done for security reasons.
That said, for your use case, you can still route a specific issue to a specific pool, comment on the issue with @Cursor and pool=<name>.
Basically… I’m really hoping that I wouldn’t have to @-mention Cursor in a comment, but could just assign the Linear ticket to Cursor and, given a label or text in the ticket, it would know what repo and what pool to run in.
On our side, worker-pool labels on a Linear issue aren’t actually read for routing (only repo, branch, and model are) — so a triage rule stamping a pool/ label shouldn’t be doing anything.
…We actually want the pool/ label to do something (or pool= text).
We have a similar use case that is not being served by Cursor’s self-hosted routing rules but for monorepos. Posted here: Self-Hosted Routing for Monorepos
