Connecting Linear to AI Coding Agents

Published July 23, 2026 · by the AQ team

Connecting Linear to an AI coding agent means wiring the place where work is specified (the issue) to the place where an agent writes code, without letting the two drift apart. As of July 2026 there are four practical routes: open the issue directly in a coding tool like Claude Code or Cursor, give the agent read and write access to Linear through the hosted MCP server, delegate the issue to a cloud agent from Linear's agent directory, or use a label-driven harness that turns issues into prepared agent workspaces. The routes differ most on a single question: does the tracker start the agent, or does a person?

What a Linear integration has to move

The issue tracker is where work gets defined, prioritized, and assigned, which makes it the natural entry point for agent work. Any integration worth using has to move three things:

• Context in. The issue title, description, comments, and linked references are the spec. The agent should start with all of it, not a paraphrase.
• Status back. When work starts, progresses, and lands as a pull request, the issue should reflect it without a human transcribing updates.
• Ownership. Someone has to be accountable for what the agent produces, and the tracker's assignee field is where the rest of the company looks for that answer.

Every route below is a different tradeoff between those three flows and one more variable the tracker cannot see: where the agent executes.

Route 1: open the issue in your coding tool

Linear ships a direct handoff for local agents. In Settings, under Code and reviews, you can enable coding tools such as Cursor, Claude Code, and Codex; from any issue, the Work on issue menu (press W then O) opens the issue in your chosen tool, carrying the issue's data plus a customizable prompt template with standing instructions, as of July 2026.

This is the simplest integration: the agent runs on your machine, under your accounts, and you are present for the whole session. The limit: a one-shot handoff. The agent gets the issue as it existed at launch, new comments do not reach it, and nothing syncs back. Status updates and the PR link are your job.

Route 2: let the agent read and write Linear over MCP

Linear runs a hosted MCP (Model Context Protocol) server that gives any compatible agent structured access to your workspace: tools for finding, creating, and updating issues, projects, and comments. It uses Streamable HTTP at mcp.linear.app/mcp, authenticates with OAuth 2.1, and offers a read-only endpoint (mcp.linear.app/mcp/readonly) when you want an agent that can look but not touch, as of July 2026.

# Claude Code
claude mcp add --transport http linear-server https://mcp.linear.app/mcp

# Codex CLI
codex mcp add linear --url https://mcp.linear.app/mcp

With the server connected, the agent itself becomes the integration: ask it to pull the issue and acceptance criteria before coding, post its plan as a comment, or move the issue when the PR is up. This composes with route 1 (open the issue in the tool, let the tool talk back through MCP) and with any harness, because the connection lives in the agent CLI's configuration.

The tradeoff: the tracker only gets updated when the agent is told to update it, and MCP says nothing about where the agent runs, whether the session survives your laptop closing, or how a teammate could see what it is doing.

Route 3: delegate the issue to a cloud agent

Linear's agent platform treats agents as app users in the workspace. An admin installs an agent from the integrations directory and grants it team access; anyone on those teams can then delegate an issue by assigning it to the agent or @mentioning it in a comment. Delegation deliberately does not transfer ownership: the human teammate remains the assignee and stays responsible for the work. Workspaces can also set agent guidance (markdown instructions at the workspace and team level that agents receive automatically), and on Business and Enterprise plans, triage rules can delegate incoming issues to an agent with no human in the loop at all. Agents do not consume billable Linear seats; you pay the agent vendor separately, as of July 2026.

The major coding agents all plug into this model, per their own documentation as of July 2026:

• Cursor. Delegate an issue to @Cursor or mention it in a comment and a cloud agent launches, pulling in the issue details, comments, and linked references. When it finishes, it updates the issue with a pull request, and progress is visible in Linear, Cursor's web app, or the IDE.
• OpenAI Codex. Mention @Codex or use Delegate on an issue that points to a GitHub-backed repository with a Codex cloud environment configured. Codex creates a cloud task and replies on the issue with progress and results; triage rules can auto-delegate, running under the issue creator's account.
• GitHub Copilot coding agent. Assign a Linear issue to Copilot and it works in its own ephemeral development environment and opens a draft pull request.
• Devin. Assign the issue to Devin, mention @devin, or apply a devin label; automation triggers can start sessions based on team, label, or status.

This is the most automated route, and its costs follow from that. Execution happens in the vendor's cloud, on the vendor's terms, with the vendor's model billing. The session is not something you sit in: you find out what the agent did when the PR and status comments arrive, and steering means another round trip through comments. And a triage rule that delegates automatically will produce unreviewed diffs faster than a team reviews them; the constraint is almost never generation speed, it is review bandwidth.

Route 4: build your own on webhooks

Linear's developer platform supports custom agents: the Agent Interaction API and SDK (a developer preview as of July 2026) deliver agent session events by webhook, and the full GraphQL API is available underneath. The simpler pattern is a webhook consumer that watches for a label or status convention and drives infrastructure you already own: create a branch, prepare an environment, notify a channel. That keeps execution wherever you want it, at the cost of building and operating the glue: webhook handling, retries, status sync in both directions, and cleanup when issues are canceled.

The routes at a glance

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. Its Linear integration is route 4 built as a product, with one deliberate opinion: label an issue "ai-task" and a workspace appears for the team, but no agent launches until a person launches it.

The workspace the label creates is an isolated git worktree on its own branch with dependencies installed automatically, ready before anyone types a prompt. Status syncs both ways between the issue and the workspace, and workspace ownership follows the Linear assignee, so the tracker and AQ agree on whose work it is. When someone opens the workspace, they start the agent themselves: Claude Code, Codex, Cursor Agent, Kimi, Grok, or a plain shell, running as a real CLI in a persistent tmux session on the team's VM and streamed live to the browser. The session survives a closed laptop, teammates can open the same workspace and see and steer the same live session, and there is no shared multi-tenant execution tier: your agents run on your VM. Agents commit, push, and open pull requests with each user's own GitHub auth, and those PRs are tracked on the workspace. Each engineer signs into the CLIs with their own Claude or OpenAI account, and AQ never marks up model usage. The step-by-step loop is written up in the Linear coding agent workflow guide.

Plainly: if you want fire-and-forget automation, route 3 is built for exactly that, and the vendors above do it well. AQ is for teams that want the tracker wired to agent workspaces on their own infrastructure, with a live session anyone can inspect and a person deciding when each agent starts, so agent output stays matched to what the team can actually review. The Free plan is the full product on a VM you bring (you pay only your cloud provider); the Team plan is $100 per user per month (promotional; standard $200, billed monthly) and includes a dedicated always-on VM managed by AQ in its own isolated network, with the rate locked for your first 12 months.