--- title: "Linear" description: "Delegate Linear issues and route mentions into Hoplite project work." canonical_url: "https://hoplite.sh/docs/integrations/linear" markdown_url: "https://hoplite.sh/docs/integrations/linear.md" --- # Linear URL: /docs/integrations/linear LLM index: /llms.txt Description: Delegate Linear issues and route mentions into Hoplite project work. Related: /docs/integrations, /docs/threads, /docs/agent/tools # Linear Connect Linear to delegate issues to Hoplite agents directly from your issue tracker. ## Setup 1. **Install** — under **Settings → Integrations**, connect your Linear workspace. 2. **Bind (optional for agent tools)** — in the selected project's area of **Settings → Integrations**, bind a Linear **project or team** to a Hoplite project when mentions and delegated issues from that part of Linear should route into this project. A binding narrows that project's agent to the selected Linear workspace; it is not required for default agents to use the organization's connected Linear tools. ## Working with issues Once connected, MCP-capable default parent agents receive Linear's built-in MCP tools for every active Linear workspace in their organization. When a project has an enabled Linear binding, its agents use that bound workspace instead. Linear issues also surface on the **Issues** page in Hoplite. Delegating an issue kicks off agent work against the bound project, with the issue's context carried into the run — and progress flows back to where the team is watching. From an issue row or its detail page, choose **Spawn thread** to open the new thread dialog prefilled with the issue title, description, and Linear identifier. The dialog stays scoped to the project that supplied the issue, so the resulting thread links and executes against the correct repository. ## Choosing a repository for delegated issues For projects connected to several repositories, add a `repo:` label to an issue before delegating it. Names are case-insensitive: `repo:api` matches `acme/api`, and `repo:acme/api` names the full repository. Use the full name when two connected repositories share a short name. An unknown or ambiguous repository label stops delegation instead of silently choosing another repo. Issue descriptions are treated as context, never as explicit routing overrides. Hoplite chooses the repository in this order: 1. The issue's `repo:` label. 2. A configured route for the issue's Linear project, then a matching label route. Conflicting label routes stop delegation unless they name the same repo. 3. For multi-repository projects, a repository classifier when enabled. It selects one repository only when its confidence reaches the configured threshold (0.9 by default). With the opt-in repository-set policy enabled, Hoplite may attach up to three repositories when an issue is ambiguous, in probability order. The first is primary; the rest are additional repositories. This policy is off by default. 4. The Hoplite project's primary repository. 5. The existing deterministic repository fallback. The classifier sends the issue title, description, and labels, along with repository metadata, to a model provider. It defaults to Jev through OpenRouter. With repository sets enabled, the classifier adds repositories until they cover 95% of the probability mass among repositories, with a maximum of three. If `none` is the most likely option or three repositories cannot cover that mass, it falls back to primary. Without this policy, low confidence falls back as before. An explicit abstention, a provider error, or fewer than two usable repository cards leaves selection to the primary repository. Single-repository projects never call the classifier. Repository cards are built lazily and refreshed after 24 hours; card loading has a shared five-second budget, and inference has a two-second timeout with no retries or provider fallback. Configure routes under **Settings → Integrations**: open the project's **Linear** integration and use **Repository routing**. **Add route** sends issues from a Linear project, or with a label, to one repository. **Pick from the issue** turns the classifier on or off for the project; when it isn't sure, Hoplite uses the primary repository. Routing applies to projects with more than one repository. Organization owners and administrators can change routes and the toggle. Choose the primary repository under **Settings → Project → Repository** with **Make primary**. New threads start in the primary repository, and delegated issues fall back to it. You can also manage routes, the classifier toggle, and the primary repository through the [repository routing API](#repository-routing-api). Routes can only select repositories connected to the Hoplite project and are scoped to the connected Linear workspace. When several repositories are available and no issue-level override was used, the Linear session names the attached repositories and explains the `repo:` override. Changing a label affects new delegations, not an already-running thread. ### Repository routing API All paths below are relative to `/api/projects/{projectId}`. Reads require project access; writes require a signed-in organization owner or administrator. | Method | Path | Request | Success response | | --- | --- | --- | --- | | GET | `/primary-repository` | None | `{ ok: true, repositoryRowId: string \| null }` | | PUT | `/primary-repository` | `{ repositoryRowId: string \| null }` | `{ ok: true, repositoryRowId }` | | GET | `/linear-repository-routes?workspaceId=...` | None | `{ ok: true, routes: Route[], linearRepoClassifierEnabled: boolean \| null }` | | PATCH | `/linear-repository-routes` | `{ linearRepoClassifierEnabled: boolean \| null }` | `{ ok: true, linearRepoClassifierEnabled }` | | POST | `/linear-repository-routes` | Route configuration | `{ ok: true, route: Route }` | | PUT | `/linear-repository-routes/{routeId}` | Full replacement configuration | `{ ok: true, route: Route }` | | DELETE | `/linear-repository-routes/{routeId}?workspaceId=...` | None | `{ ok: true, id: routeId }` | Set `linearRepoClassifierEnabled` to `false` to disable automatic classification for a project. `true` or `null` enables it, subject to the platform kill switch and availability of the platform provider key. The PATCH request does not need a Linear workspace ID. The **Pick from the issue** toggle in Repository routing sets the same value. A route configuration contains `workspaceId`, `repositoryRowId`, and exactly one of `linearProjectId` or `label`. Labels are trimmed and lowercased. A `Route` contains `id`, `orgId`, `projectId`, `workspaceId`, `repositoryRowId`, nullable `linearProjectId` and `label`, and ISO `createdAt` and `updatedAt`. Setting the primary repository to `null` restores the deterministic fallback. Duplicate selectors return HTTP 409; invalid bodies return 400; missing or out-of-scope projects, repositories, installations, and routes return 404. ## Linked issues in threads The agent attaches Linear issues to [threads](/docs/threads) with `other_thread_control` and `op: "link_linear_issue"`. It uses the [tool](/docs/agent/tools) proactively when a prompt includes an issue reference, and inbound Linear agent sessions attach the originating issue automatically. The linked issue appears as the compact Linear pill used alongside pull requests in thread views. Linking only stores Hoplite thread metadata; it does not read from or write to Linear. Agents use Linear's read and write tools only when you explicitly ask them to access Linear. Linking an issue, working on its implementation, or opening a pull request does not by itself authorize the agent to read or change Linear. ## Sitemap Sitemap discovery is not enabled for this deployment.