Linear MCP vs Aident Loadout for Codex: Which Should You Use?

Use Linear's official MCP server when Codex needs a focused, provider-native connection to Linear, especially when an explicit read-only boundary matters. Use Aident Loadout when the same agent needs to discover and inspect Linear actions alongside other applications, keep credentials in a shared Vault, preview costs, and execute through one audited integration layer.

Neither route is universally better. The right choice depends on the boundary of the job.

The short answer

The practical rule is simple: choose Linear MCP for direct Linear access; choose Aident Loadout for an orchestrated workflow in which Linear is one system among several.

What Linear's official MCP server gives Codex

Linear's MCP documentation lists https://mcp.linear.app/mcp as the primary Streamable HTTP endpoint. The server uses OAuth 2.1 with dynamic client registration, and Linear also accepts a bearer token or API key for clients that support header-based authentication. Linear's older SSE transport is deprecated.

Codex has a first-party setup path. Linear's Codex MCP integration page and OpenAI's Linear connector guide use this command:

codex mcp add linear --url https://mcp.linear.app/mcp

Then authenticate when Codex prompts you.

The strongest reason to choose this route is the access boundary. Linear says its standard endpoint is read-write by default, but you can use https://mcp.linear.app/mcp/readonly or request the read OAuth scope. If the task is "summarize this cycle without changing anything," that provider-enforced boundary is clearer than relying only on a prompt.

The official server is also evolving with the product. Linear's February 2026 MCP update added tools for initiatives, milestones, and project updates. Treat the live tool list as the contract rather than copying a permanent list into an agent prompt.

What Aident Loadout gives Codex

Aident Loadout is an integration layer rather than a Linear-specific server. Codex searches for the actions required by the current job, inspects their live input schemas, verifies the connection in Vault, and executes the selected action. The same sequence applies when the workflow later moves from Linear to GitHub, Slack, or another connected application.

Start with the public setup instructions:

Follow https://aident.ai/SETUP.md

Then verify the account and the Linear connection before searching for actions:

aident account auth status
aident vault vault --action status --integrationId linear_tools
aident capabilities search \
  --queries '["list Linear teams and issues read-only","create a Linear issue from an approved result"]' \
  --types '["action"]' \
  --targetEnv staging

Keep the exact action names returned by discovery. Inspect the selected action's schema, then preflight its exact input before execution. This prevents a model from inventing field names or discovering too much of the catalog at once.

The advantage becomes concrete in a cross-application job. Suppose Codex must find a failing GitHub check, locate the related Linear issue, add evidence, and draft a Slack update. Linear MCP covers the Linear part well. Loadout can keep the entire sequence behind one discovery, Vault, preflight, execution, and audit pattern.

A current contract check

On August 26, 2026, we checked the live Loadout catalog rather than relying on a cached integration list. Linear OAuth was connected. Discovery returned active actions for listing teams, listing and searching issues, getting an issue, listing projects, and creating an issue.

We inspected the current schema for the team-listing action, preflighted an input with first: 20, and executed it. The action returned a valid page with hasNextPage: false. We did not create or update an issue because a connectivity check should not mutate a real workspace.

This is a contract check, not a speed benchmark. It proves that discovery, schema inspection, connection resolution, preflight, and one read path worked together on that date. It does not prove that every Linear action or every workspace permission will behave identically.

Where the tradeoffs actually matter

Read-only control

Linear MCP has the cleaner hard boundary for a Linear-only audit because Linear documents a dedicated read-only endpoint. With Loadout, search for read actions, inspect the exact schema, and keep the approved action set narrow. Do not turn "read only" into a vague sentence while still exposing write actions.

Tool discovery

Linear MCP lets the MCP client discover the tools served by Linear. Loadout lets the agent search a broader catalog by intent and fetch the schema for only the selected action. The former is simpler for one provider; the latter is useful when the provider is not known until the job is planned.

Authentication

Both routes can use OAuth. Linear MCP authenticates the MCP client directly with Linear. Loadout resolves the user's Linear connection from Vault and applies the same credential workflow across integrations. Never place an API key in a prompt, shell history, or issue body.

Cost visibility

Linear's official MCP documentation does not describe an Aident action charge. Loadout preflight can return the current action price before execution, or state that an exact estimate is unavailable. Use the returned preflight result rather than assuming that every read is free.

Cross-application work

This is the clearest dividing line. If the workflow begins and ends in Linear, the official MCP connection is usually the smaller surface. If the desired outcome crosses several systems, Loadout avoids wiring and auditing a separate connection pattern for every step.

A safe evaluation you can run

Test both routes on the same non-destructive job:

Read only. List no more than 20 Linear teams. Find open issues for one approved team and summarize title, status, assignee, and updated time. Do not create, update, comment on, or archive anything. Show the tool or action schema and authentication state before execution. If a cost applies, show the preflight first. Do not reveal credentials.

Score the result against observable checks:

1. Did authentication complete without exposing a secret?

2. Was the tool or action contract visible before execution?

3. Did the route enforce or preserve the read-only boundary?

4. Did pagination stay bounded?

5. Could you identify what executed afterward?

6. Could the same workflow add another application without rebuilding the control plane?

Do not compare the routes using different tasks. A narrow read-only query on one side and a multi-application write workflow on the other would measure job design, not the integration layer.

Common failure modes

If Codex can authenticate but cannot see the expected Linear data, check workspace membership and OAuth scopes before replacing the integration. If the official MCP route can read but not write, confirm that you did not intentionally select the read-only endpoint or scope.

If a Loadout action rejects its input, reload the live schema instead of guessing. Action contracts can change. If preflight reports an approval requirement or unavailable estimate, stop at the gate and resolve it explicitly. A successful connection status does not authorize every action.

For either route, start with bounded reads. Resolve team and issue identifiers before any write, show the proposed change, require approval, and re-read the target after execution. These checks matter more than which transport carried the request.

Which should you choose?

Choose Linear MCP when:

• Linear is the only external system in the job.

• You want Linear's provider-native MCP experience.

• A documented read-only endpoint is an important policy boundary.

• Your client already manages MCP authentication and tool permissions well.

Choose Aident Loadout when:

• Linear is one step in a broader workflow.

• The agent must discover capabilities by intent.

• You want a consistent Vault, schema, preflight, execution, and audit sequence.

• You expect to add or replace integrations without rewriting the entire workflow.

You can also use both. Keep the official Linear MCP server for tightly scoped, read-only Linear context, and use Loadout for approved cross-application actions. What matters is that each route has a distinct responsibility and that the agent cannot silently choose a broader write surface.

The next step

Run the read-only evaluation above with one real but non-sensitive Linear project. If the job stops at Linear, keep the direct route. If it naturally expands into a multi-application sequence, compare one Loadout setup using the same acceptance checks.

For the wider architecture decision, read Agent Skills vs MCP vs CLI. If you choose Loadout, continue with How to Use Aident Loadout, then review how to give AI agents API access without exposing keys.

Recheck this comparison when Linear changes its MCP scopes or transport, when the Loadout Linear action contract changes, or when your workflow adds another system. The best choice follows the job boundary, not a permanent vendor ranking.