ankitpokhrel/jira-cli: an interactive Jira client for the terminal

What JiraCLI replaces, and who feels the pain

The Jira web UI is a browser tab, a session, and a sequence of clicks between you and a one-line issue update. JiraCLI is an interactive command line tool for Atlassian Jira that, in the README's own words, helps you "avoid using the Jira UI to some extent". The project started with issue search and navigation as its core idea and later grew issue creation, cloning, linking and ticket transition.

The audience is narrow and identifiable. If your day is a terminal, a branch, and a ticket key, the round trip to a browser is the tax you pay per issue. JiraCLI is for that person. It is explicitly modelled on the GitHub CLI, so anyone who already reaches for gh will recognise the shape: authenticate once, then run subcommands against the remote service.

It is not a Jira replacement, and the README is honest about that: the tool "may not be able to do everything". Administration, permission schemes, workflow editors and board configuration stay in the browser. Treat JiraCLI as a client for the work you do repeatedly, not as a second interface to the whole product.

How JiraCLI talks to Jira: config file, token, API

The architecture is a single Go binary that authenticates to the Jira REST API and renders results either as plain output or as a terminal UI. The dependency list in go.mod confirms the shape of it: cobra for the command tree, viper for configuration, survey for interactive prompts, tview and tcell for the full-screen terminal interface, and glamour plus blackfriday for rendering formatted text.

Configuration is generated, not hand-written. You run jira init, choose an installation type, and the tool writes a config file that later commands read. Credentials come from the environment: JIRA_API_TOKEN carries an API token on Cloud, or a password under basic auth on-premises, or a personal access token when you also set JIRA_AUTH_TYPE to bearer. The README notes that .netrc or keychain can supply the token instead of a shell export.

There is a second consumer beyond humans. The repository ships an llm.md file aimed at agents, and the README states that JiraCLI "works well with LLM-powered CLI tools like Claude Code, Codex, OpenCode, as well as shell-based automation". That is the interesting design bet: a stable command surface is useful both to a person typing and to a program calling it.

The repository also carries a docker-compose.yml that starts atlassian/jira-software:9.14.0 alongside postgres:12.9-alpine. That is a local Jira for development, not part of the shipped tool, and it is worth knowing before you wonder why a CLI needs a database.

Installing jira-cli and running a first command

The README points to packaged binaries for Linux, macOS and Windows on the releases page, and defers Homebrew, Nix and other methods to the project's installation wiki. The fastest way to see the tool without touching your system is the published container image:

docker run -it --rm ghcr.io/ankitpokhrel/jira-cli:latest

The repository's own Dockerfile documents the equivalent local build and a run command that mounts your credentials and generated config into the container, which is the pattern to copy if you want the container to be usable rather than just startable:

docker build -t jira-cli:latest .
docker run --rm -it -v ~/.netrc:/root/.netrc -v ~/.config/.jira:/root/.config/.jira jira-cli

For a normal install, the README's Cloud steps are to get an API token, export it to your shell as a JIRA_API_TOKEN variable, and then run jira init, selecting installation type Cloud and providing the required details to generate the config file. On-premises, the choice is Local instead, and the README notes that the most common auth type there is basic; a personal access token is exported the same way, with JIRA_AUTH_TYPE set to bearer in addition.

After init completes, the reader should have a working jira command whose subcommands operate against the configured instance. The README does not enumerate every subcommand on the front page; the commands live behind the binary itself and in the project wiki.

Where JiraCLI breaks: locales, Windows and the missing UI

The sharpest documented failure mode concerns on-premises Jira in a language other than English. The README carries an important note: issue and epic creation may not work, because the older Jira API does not return the untranslated name for issuetypes. The workaround is manual. You edit the generated config and fill in epic.name, epic.link and the issue.types.*.handle fields yourself. That is a real cost, and it lands precisely on the teams least likely to have spare time.

Platform support is uneven. Linux, macOS, FreeBSD and NetBSD are marked as supported; Windows is marked partial. If your team is on Windows and expects the interactive interface to behave like the demo, the support table is the thing to read before promising anything.

Cloud and on-premises are not identical either. The README warns that some features "might work slightly differently in Jira Cloud versus on-premises installations due to the nature of the data", while noting the project tried to keep the experience similar. Similar is not the same, and the difference will surface in edge cases rather than in the first five minutes.

Finally, the tool is not a Jira UI replacement in any complete sense. If your work is triaging boards, editing workflows, or reading rich issue history with attachments and inline images, the browser remains the right surface. JiraCLI is a fast path for a defined set of operations, and it should be judged on that.

JiraCLI versus Atlassian's own CLI and versus MCP

The obvious alternative is Atlassian's own CLI, commonly abbreviated acli. The difference is in what each is built around. JiraCLI is an interactive, human-first client: survey prompts, a tview terminal interface, and commands shaped for navigating and editing issues from a shell. Atlassian's CLI is the vendor's own tool for the Atlassian platform, which matters if you want the vendor's roadmap and support boundary rather than a community project's.

A second comparison is architectural rather than product-level. People increasingly reach for an MCP server to let an assistant touch Jira, and the related searches show that confusion is live. JiraCLI takes the opposite route: instead of exposing a protocol for a model to call, it exposes a command line that a model can already use, which is why the repository ships llm.md for agents and the README names Claude Code, Codex and OpenCode as compatible tools. If your goal is agent access, the question is whether you want a protocol server or a CLI that an agent shells out to. JiraCLI bets on the latter.

Neither comparison is settled by feature counts. Pick Atlassian's CLI if vendor alignment is the deciding factor; pick JiraCLI if the interactive terminal experience and the agent-via-shell pattern are what you actually want.

Maintenance, licence and what an upgrade costs

The repository is not archived and the last push was on 2026-09-22, so the project is being worked on. Release cadence is visible in the tags: v1.7.0 on 2025-08-31, v1.6.0 on 2025-04-19, and v1.5.2 on 2024-09-22. That is roughly two releases a year, with the most recent one about a year before the latest push. The README also states that financial support from sponsors "ensures the tool's continued development", and Atlassian and JetBrains appear as supporters. That is a funding model worth knowing about, because it is the project's own stated dependency.

Upgrade cost is low in the normal case. It is a single static binary with CGO disabled in the Makefile, so replacing it is a file swap rather than a dependency resolution problem. The risk sits in the generated config, not the binary: the locale workaround described above means some installations carry hand-edited epic.name, epic.link and issue.types entries that a config regeneration could overwrite. Back that file up before you re-run jira init.

Licensing is MIT, which permits commercial and internal use with minimal conditions and requires preserving the copyright notice and licence text. That is a statement about the licence text, not legal advice; if your organisation has a policy on bundled notices, route it through whoever normally handles that.

Editorial conclusion

Adopt JiraCLI if you search, create and transition Jira issues from a terminal all day, and if your instance is Jira Cloud or a Jira Server install whose language is English. Do not adopt it if you need full Jira administration, if you are on Windows and depend on the interactive TUI, or if your on-premises Jira runs in a non-English locale and you are unwilling to edit the generated config by hand. Before rolling it out, run jira init against one project and confirm that issue.types and epic fields resolve correctly for your instance.

Frequently asked questions

Official sources

1. ankitpokhrel/jira-cli on GitHub
2. Issues
3. License: MIT
4. README
5. Releases