T3 Linear Bridge

Recent runs

Linear → T3 → GitHub execution state

Issue	Repository	Workflow	Runtime	Updated

Durable queue lanes

Pending work, retries, age, and most recent successful processing

Queue	Source	Pending	Retrying	Oldest	Dead letters	Last success

Dead letters

Sanitized failures quarantined after permanent errors or bounded retries

Queue	Kind	Attempts	Error	Quarantined

Safe configurationChanges are validated, versioned, audited, and applied to new work immediately. Saving is never blocked by work in progress: a run already executing keeps the policy, backend, and route it resolved when it started, and the new settings apply to everything that starts from now on.

General

Public links, upstream APIs, and reconciliation cadence

Public bridge URL Linear GraphQL endpoint GitHub API URL Active polling interval Always-tagged agent user

Every T3 session the bridge creates is owned by the human who started the Linear run and additionally tags this agent account, matched by email. Leave it empty for the default; an address with no matching T3 user is logged and skipped.

Maximum CI repair attempts

Suggestion confidenceMinimum lead

Linear response chunk size Stale run timeoutA run whose backend goes quiet this long is closed so its capacity returns. Use 0 to switch it off.

Two-way session sync

T3 prompts → Linear T3 responses → Linear

Session attention notifications

Aggregate unresolved T3 requests and DM every person tagged on the shared session

Mattermost

Enable notifications Aggregation window Mattermost URL

Tagged T3 users are resolved to Mattermost accounts by email and exact display name, and each receives a direct message. Replying to the DM answers the session. Requests answered before the window closes are suppressed.

Mattermost surface

Mention the bot in a channel to start a T3 session there; tagged thread replies continue it

Enable channel listener Bot username Default route

Routes map a channel onto the T3 environment and project a mention starts in. A mention can select any route inline with in <route>: message. The listener requires the dedicated bot token below; channel membership is the permission gate — invite the bot to a channel to allow it.

MCP toolkitTools every T3 session can call at POST /mcp/mattermost with the MCP bearer secret; sends post as the bot and bind their threads so replies route back into the calling session, and attach_session relays a whole session into a DM thread

Experimental PR session automation

Send failed checks, deployments, comments, and reviews to the T3 session already linked to the pull request

Experimental

Enable automation Aggregation window Mapping reconciliation Consecutive turn limit Maximum prompt context Excluded GitHub usernames

Usernames use case-insensitive exact matching. Automation starts disabled, establishes a baseline from current links, waits for an idle execution revision, and pauses after the configured turn limit.

Ticket-size execution profiles

Choose how every Linear complexity starts in T3 Code. Model overrides are optional; without one, the selected repository's model is used.

New runs only

Planning controls plan approval versus direct implementation.Access maps exactly to T3 Code runtime permissions.Model settings support provider-specific reasoning, speed, thinking, and future option IDs.

Custom Linear label overrides

Override selected execution fields when a Linear label matches. Rules run from top to bottom; later matching rules win only for fields they set.

Wildcards use * for any text and ? for one character.Inheritance keeps the size/repository value whenever a field is blank.Safety keeps Risk: High in Plan mode even if a rule requests direct implementation.

T3 environments

Execution capacity and project hosts

Hermes backends

Autonomous assistant gateways the bridge hands a task to instead of driving

Backend ids share one namespace with T3 environments because a run records exactly one of them. A Hermes run has no plan, approval, or pull request: the bridge starts the task, mirrors progress, and publishes the answer.

Repository routes

Allowlisted mappings from Linear issues to T3 projects

Default repository for unlabeled sessions

Explicit repository labels and unique team mappings always win. Leave this empty to restore Linear suggestions and blocking when no route matches.

Integration secrets

Write-only values encrypted with AES-256-GCM; leave blank to retain the current value

GitHub token Clear configured value GitHub webhook secret Clear configured value Mattermost delivery token · legacy Clear configured value Mattermost bot token · @bkt3 surface Clear configured value MCP toolkit bearer Clear configured value

Linear applicationsOne API token and webhook signing secret per application id. The id appears in the public path POST /webhooks/linear/{app}, so it must be 1-64 lowercase letters, digits, hyphens, or underscores. A preferred backend pins the agent runs this application starts execute on; the repository route must still map that backend.

Linear API token · default application Clear configured value Linear webhook secret · default application Clear configured value Preferred backend · default application

T3 environment tokensOrchestration bearer credential per environment; the environment's tokenEnv variable remains the fallback

Hermes backendsAPI server key and outbound webhook signing secret per backend id. Without the webhook secret the endpoint accepts nothing and the transcript poll carries the integration on its own.

Authentication boundary

Integration health

One row per Linear application and per execution backend, probed under its own credential

A connected Linear application reports the app user id and display name its token resolves to, so it is visible which identity the bridge is acting as. Credentials themselves are never returned.

Checking Linear applications, execution backends, GitHub, and Mattermost…

Linear applications

Each agent is its own Linear application, with its own identity, credentials, and webhook path

Supply only what Linear will not give a machine: the OAuth client id, the client secret, and the webhook signing secret. Linear never exposes a webhook signing secret over its API, so that one has to be pasted — it is shown once when the webhook is created. Connect then does the rest: it builds the actor=app authorize URL with the scopes the agent needs, verifies a single-use state bound to you, exchanges the code, confirms the identity, and mints the app token. Values are write-only; only whether one is set is ever shown.

Execution backends

T3 environments and Hermes gateways: a base URL and a credential, pasted and verified here

A backend has no OAuth flow — paste and verify is the whole job. Saving writes through the same audited configuration path and the same encrypted keyed storage as everything else; the environment variable named by tokenEnv remains the fallback when no credential is stored. Add or remove a backend, and map its projects, under Configuration.

Configuration audit

Immutable history of settings revisions and secret-field changes