Linear is one of the best tools our agency uses. It is also one of the biggest context-switches in an engineer's day. Every time a ticket needs to be updated, a branch needs to match an issue ID, or a priority needs to flip, you stop coding, open a browser tab, wait for the web app to load, click through three panels, and come back. Thirty minutes later you realize you never came back.
This is Linear CLI's entire reason to exist: collapse the distance between "I need to update this issue" and "I have updated this issue" from thirty seconds of context-switch to three keystrokes.
The real problem
Most teams that adopt Linear have two types of people inside it: project managers who live in it full-time, and engineers who visit it when they have to. The PMs are fine — the web app is designed for their workflow. The engineers bleed time on the round trip. At Contra Collective we tracked this for a quarter and the number was roughly thirty minutes per engineer per day across seven concurrent client engagements. Multiply by headcount and that is real money.
A community tool called lr existed and we used it for a while. It covered "list my issues" and "create an issue" and not much else. The real time-sink in our workflow was the stuff lr did not touch: cycle transitions, workspace switching between client accounts, automatic git branch creation from issue IDs, quick status updates while you were mid-rebase. So we started extending lr internally, and then at some point we were maintaining a fork that shared only the name with the upstream.
What Linear CLI does differently
Four decisions set Linear CLI apart from the community options we started with:
- Git-native. Ticket IDs map to branch names automatically.
linear start CC-482creates the branch, updates the ticket to In Progress, assigns it to you, and drops you into a pull-request-ready state in one command. - Workspace-aware. If you run agency engagements, you live in multiple Linear workspaces. Linear CLI keeps per-workspace auth separately and switches with a single command — no re-auth flow, no sign-out dance.
- Cycle-first output. The default view is your current cycle, not your entire inbox. This sounds minor until you spend a week reading "75 issues" lists and realize you only care about this sprint's eight.
- Rich terminal UI. Built on Ink (React for the terminal), which means real keyboard navigation, fuzzy search, inline editing. Not a raw list dump.
Why it's open source
Linear CLI is MIT-licensed and free, and it always will be. The reason is simple: we built it to recover engineering time on client engagements, and every engineer we work alongside benefits from it the same way we do. Open-sourcing it increased the chance we would get bug reports and feature requests from teams outside Contra Collective — which we did, and which made the tool better faster than our internal use alone would have.
It also happens to be good marketing for the agency side. When you run an engagement with a team that already uses Linear CLI, onboarding takes fifteen minutes instead of a day. That is the kind of quiet compounding advantage we did not plan for but happily accept.
What's next
The roadmap we care about most: deeper Git integration (automatic PR linking back to the issue), native cycle retrospectives rendered in the terminal, and an API plugin system for teams that have internal tools they want to pipe Linear activity into. If any of that is interesting to you, open an issue on the GitHub repo — that is genuinely the fastest way to influence what ships next.
Linear CLI is one of the tools that gets used every working hour of every day inside Contra Collective. It earned its place on this site the way every other open-source project here did: by being the thing we reach for without thinking about it.