If you searched for a Linear CLI, you already know the first surprise: there isn't an official one. Linear ships a hosted MCP server, a GraphQL API, and a TypeScript SDK, but no first-party command-line tool. What you find instead is a healthy little ecosystem of community CLIs, and a striking number of them were built specifically so an AI agent could drive Linear from the terminal.
That tells you something. The demand for a command line on top of an issue tracker is real, it is coming from engineers who live in the terminal, and increasingly it is coming from the agents those engineers run. This post is two things: an honest map of the Linear CLI options that exist today, and the argument for why the command line should be a first-class surface the tracker ships itself, not a wrapper you bolt on.
Linear's own developer surface is the GraphQL API and SDK. Everything below it on the command line is community-built. The well-known ones, as of mid-2026:
schpet/linear-cli
linctl
Finesssee/linear-cli
These are legitimate, and several are well made. If you use Linear and want a terminal workflow, one of them will probably get you most of the way there. The honest caveat is the one every community wrapper carries: it tracks an API it does not own. When Linear changes the GraphQL schema, the wrapper has to catch up, and you are depending on a maintainer's spare time for a surface that is load-bearing in your workflow.
Linear is an excellent, GUI-first product. The keyboard craft is in the app: the command palette, the shortcuts, the speed of the interface. The command line was never the design center, so it landed in the community instead of in the box. There is nothing wrong with that choice. It is just a choice, and it has a consequence: the terminal is a second-class surface for Linear, supported by people who are not Linear.
Radial made the opposite choice. The CLI is a first-class surface, shipped and versioned with the product, sitting on the same REST API that everything else uses. It is not a wrapper around an API we reverse-engineered. It is the API, with a terminal on top.
The point of a command line on your tracker is that the work becomes scriptable. You file an issue without leaving the shell, you list your queue without a tab switch, and every command speaks --json
so the same move pipes into anything:
radial create "Investigate 500s on checkout" -t ENG -p high --json
List what is on your plate the same way:
radial list --assignee me --status "in progress" --json
Because --json
is on every command, the tracker stops being a place you visit and becomes a thing you script. CI can file an issue when a build breaks. A pre-commit hook can check what is assigned to you. And your agent can do all of it, because to the API there is no difference between you typing radial create
and Claude Code calling the same endpoint over MCP. Every credential is a client of the API, not a billed seat, so the agents ride free.
That last part is the quiet through-line of the whole Linear-CLI ecosystem. Read the descriptions again: "built for LLM agents," "purpose-built for agents like Claude Code." People are not just asking for a terminal. They are asking for a surface their agents can drive. A tracker that ships the CLI and the MCP server itself, on one API, is meeting demand the community has been improvising against for two years.
If you are coming from Linear, the migration is a command, not a quarter. Export from Linear, preview the import dry first, then run it:
radial import --from linear export.json --dry-run
Drop --dry-run
to bring your issues, projects, labels, comments, and history across for real. Your data is portable on the way out, too: one-command export is always available, so the CLI is not a trap, it is a door that swings both ways.
Not an official one. Linear ships a hosted MCP server, a GraphQL API, and a TypeScript SDK, but no first-party command-line tool. The community has filled the gap with several CLIs (schpet/linear-cli
, Linearis, linctl
, Finesssee/linear-cli
, Composio), many of them built specifically for AI agents. They work, with the usual caveat that a community wrapper tracks an API it does not own.
No, and the popularity of these agent-oriented Linear CLIs is the proof. A command line is the one interface a script and an agent can both drive without a human in the loop. As more of your workflow gets automated or handed to an agent, a scriptable, --json
-speaking surface becomes more useful, not less. The GUI is for the human; the CLI is for everything else that needs to touch the tracker.
It is first-party. The Radial CLI is shipped and versioned with the product, on the same REST API as the web app and the MCP server, so it does not lag behind a schema it does not control. A community Linear CLI is a wrapper a volunteer maintains against Linear's GraphQL API; when that API changes, the wrapper has to catch up.
No. Every agent credential is a client of the API, CLI, or MCP server, not a billed seat, and there is no usage meter anywhere in the product. You pay one flat $50 per user, per year, billed annually, for the humans, and that price is locked at the rate you join. The Plain Software Pledge backs it: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.
Linear never shipped a CLI, so the community shipped a dozen, and most of them are pointed at agents. That is demand telling you where the terminal belongs: as a first-class surface the tracker ships itself, on one API, free for the agents to drive. That is the bet Radial made.
See the developer surface on the developers page, or read how Radial compares to Linear on the one thing a cap table won't let Linear match.
Originally published on the Radial blog.