Linear Integration for Coding Agents: DevPilot's GitHub Bridge
5 min read
DevPilot's Linear integration is a bidirectional sync between Linear issues and DevPilot coding-agent sessions, run through a hosted bridge that verifies signed webhooks before anything is dispatched. It is not a comment-bot integration: assigning an issue to the bot user spawns a real agent session, and progress is synced back to Linear in real time.
What DevPilot's Linear bridge actually does
DevPilot provides bidirectional synchronization with Linear for issue tracking. That's the whole claim, and it breaks into four concrete pieces:
- Outbound sync — DevPilot sessions become Linear issues.
- Inbound sync — Linear webhooks become DevPilot dispatch events, via a hosted bridge.
- Status updates — progress is synced in real time, in both directions.
- Auto-dispatch — assigning an issue to the bot user automatically spawns an agent.
This is different from the pattern most people mean when they say "GitHub Copilot Linear integration," which is usually a comment bot that reacts to @copilot mentions inside an issue thread. DevPilot's bridge dispatches an actual agent session — currently Claude Code, the only agent wired into DevPilot — and keeps that session's state visible on the Linear board as it runs, not just at the point where someone remembers to update the ticket.
Linear is the only issue tracker DevPilot talks to. There's no Jira or GitHub Issues bridge described here — if your workflow lives elsewhere, this integration doesn't help you yet.
Architecture: the hosted bridge and signed webhooks
Linear doesn't talk to DevPilot directly. It sends a signed webhook to a hosted bridge, and the bridge is what forwards events into DevPilot's dispatch queue.
Every webhook from Linear is signed with HMAC-SHA256, and signature verification is mandatory — not optional, not a config flag you can turn off in a hurry. That matters more here than on a typical webhook consumer, because the payload on the other end doesn't just update a database row. It can trigger auto-dispatch, which spawns an agent session with real permissions on real infrastructure. An unverified webhook path on a dispatch trigger is a way to let anyone who finds the URL spawn agents on your behalf. Mandatory verification is the control that rules that out.
The bridge sits in the middle:
┌─────────────────────────────────────────────────────────────────────┐
│ LINEAR │
└────────────────────────────────┬────────────────────────────────────┘
│ signed webhook (HMAC-SHA256, mandatory)
Everything downstream of that arrow — matching the event to a session, handing it to the orchestrator, spawning the agent — is DevPilot's dispatch layer, not Linear's concern and not the bridge's concern. The bridge's job stops at "verify, then forward."
Outbound sync: DevPilot sessions become Linear issues
When a session starts in DevPilot, it's reflected as a Linear issue. You don't have to manually create a ticket to track work that DevPilot is already doing — the sync handles that direction automatically.
From there, progress and status are synced in real time. As the agent works, the issue on the board reflects what's actually happening in the session, not a stale snapshot from whenever someone last remembered to comment. This is the same real-time link that makes the dispatch queue useful as a single place to see what's running — the Linear issue is a second surface for the same state, not a separate source of truth.
Inbound sync: from Linear webhook to agent dispatch
The other direction: events in Linear — an issue created, updated, or assigned — arrive as webhooks at the hosted bridge, get verified, and are routed into DevPilot's dispatch layer.
The specific case worth naming is auto-dispatch: assign an issue to the bot user, and DevPilot automatically spawns an agent for it. No separate command, no manual trigger inside DevPilot. The act of assignment in Linear is the trigger. This is the mechanism that lets a Linear-based workflow — triage, assign, done — double as an agent-dispatch workflow, without anyone touching DevPilot directly.
What the Linear bridge doesn't cover: adopted sessions
Everything above describes work DevPilot starts. It does not describe the other direction: an agent session that's already running on your machine, that DevPilot didn't spawn and doesn't yet know about.
Discovering those sessions and placing them on a board is handled by adoption and fleet introspection — a separate mechanism, documented in docs/ADOPTION.md and spec/trd/21-FLEET-INTROSPECTION.md — not by the Linear bridge. If you're looking for "how does DevPilot find an agent I started manually and put it on Linear," that's not this integration. Conflating the two is the most common way to misread what the bridge does: it syncs work DevPilot dispatched, full stop.
Where this fits in your workflow
The Linear bridge is one half of the picture — it needs an agent to actually dispatch, which today means Claude Code. If you're already running agents through an editor or CLI setup, the bridge slots in as the tracking and dispatch-trigger layer on top, not a replacement for it.
If you're setting this up, the practical next steps are: configure the hosted bridge, confirm webhook signature verification is active rather than assumed, and grant the bot user the Linear permissions it needs to receive assignments. Full setup detail lives on the Linear integration page, and the broader set of tools DevPilot connects to is listed on the integrations overview. If you're weighing how many agent sessions this setup can realistically carry before dispatch becomes the bottleneck, that's covered separately in how many agents you can run at once — not something this integration itself answers.