jira
An agent-friendly Jira CLI for Jira Cloud and Jira Data Center / Server.
- Auto-JSON when stdout is not a TTY, so you can pipe it anywhere and get structured data
jira schemadumps every command, flag, and JSON shape as machine-readable JSON for agent introspection- Structured exit codes, so agents can branch on auth failures, rate limits, not-found, and input errors without parsing text
- Clean stdout/stderr split: data on stdout, messages on stderr,
--quietsuppresses all non-data output
$ jira issues list --project MYAPP --status "In Progress"
KEY SUMMARY STATUS ASSIGNEE
MYAPP-42 Fix login redirect loop In Progress Alice
MYAPP-38 Update password reset flow In Progress Bob
$ jira issues list --project MYAPP --json
{"total": 2, "issues": [...]}
Installation
Or via Cargo:
Or build from source:
Configuration
Run jira init for a guided setup, or create the config file manually.
Default locations:
| Platform | Path |
|---|---|
| Linux / macOS | ~/.config/jira/config.toml (or $XDG_CONFIG_HOME/jira/config.toml) |
[]
= "mycompany.atlassian.net"
= "me@example.com"
= "your-api-token"
Get a Jira Cloud API token at: https://id.atlassian.com/manage-profile/security/api-tokens
Run jira config show to confirm the resolved path and active credentials (token is masked).
Environment variables
All credentials can be set via environment variables, which is useful for CI and scripts:
| Variable | Description |
|---|---|
JIRA_HOST |
Atlassian domain (e.g. mycompany.atlassian.net) |
JIRA_EMAIL |
Account email |
JIRA_TOKEN |
API token or Personal Access Token |
JIRA_PROFILE |
Config profile name |
JIRA_AUTH_TYPE |
basic (default) or pat |
JIRA_API_VERSION |
3 (Cloud, default) or 2 (Data Center / Server) |
JIRA_READ_ONLY |
Block write operations. On: 1, true, yes, on. Off: 0, false, no, off. Any other value is an error, not "off" |
JIRA_DEBUG_HTTP |
Include the raw Jira response body in API error messages (1, true, yes, on). Useful when the default summary is ambiguous. |
Values are matched case-insensitively. JIRA_AUTH_TYPE and JIRA_API_VERSION reject anything outside the values listed above rather than falling back to the default, so a typo surfaces as a config error instead of an unexplained authentication failure.
Multiple profiles
[]
= "mycompany.atlassian.net"
= "me@example.com"
= "cloud-token"
[]
= "jira.corp.com"
= "personal-access-token"
= "pat"
= 2
Switch with --profile dc or JIRA_PROFILE=dc jira <command>.
Jira Data Center / Server (PAT auth)
Data Center uses Personal Access Tokens instead of email + API token:
[]
= "jira.corp.com"
= "your-personal-access-token"
= "pat"
= 2
Email is not required for PAT auth. Get your token at:
https://<your-host>/secure/ViewProfile.jspa?selectedTab=com.atlassian.pats.pats-plugin:jira-user-personal-access-tokens
Usage
Issues
# List
# Assigned to you
# Show
# Create
# Update
# Transition
# Assign
# Comment
# Log work
# Attachments
# Links
# Move to sprint
# Bulk operations (use --dry-run to preview)
Projects
Search
Boards and sprints
Users and fields
Shell completions
# Install automatically (bash, zsh, fish)
# Or redirect manually
Config
Agent use
jira schema returns a complete, machine-readable description of all commands, flags, JSON output shapes, auth requirements, and exit codes. AI agents should call this once at the start of a session instead of relying on help text.
|
|
Read-only mode
Set JIRA_READ_ONLY=1 to block every command that writes to Jira. The CLI returns exit code 2 with a structured error for any blocked command, before it opens a connection. This is useful when giving an AI agent read access to Jira without the risk of unintended modifications.
The guard covers writes to Jira, not writes to your disk: jira init, jira config init, jira config remove and jira issues download-attachment still work, because they change local files only.
jira schema lists the blocked commands under read_only.blocked_commands, so an agent can see what it is allowed to do without trying:
|
A value the CLI does not recognise (JIRA_READ_ONLY=enabled, or a typo) is rejected as a config error rather than read as "off", so a mis-set guard fails loudly instead of quietly allowing writes.
You can set it in the config file:
[]
= true
Or per-profile:
[]
= true
When giving an AI agent access to the CLI, set the env var in the agent's configuration. For example, in Claude Code's .claude/settings.json:
Any agent that supports environment variable configuration can use the same approach.
Exit codes
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | Unexpected error |
| 2 | Bad input or config error |
| 3 | Authentication failed |
| 4 | Resource not found |
| 5 | Jira API error |
| 6 | Rate limited |
| 7 | Target already exists (pass --force to overwrite) |
A downstream that stops reading, as in jira issues list | head -5, terminates
the CLI with SIGPIPE rather than any of these codes. That is what every other
member of a pipeline does, and shells report it as 141.
Output flags
| Flag | Effect |
|---|---|
--json |
Force JSON output (auto when stdout is not a TTY) |
--quiet |
Suppress counts, confirmations, and status messages |
Both flags are available on every command.
Development
Running e2e tests
The e2e test suite runs against a real Jira instance. A Jira Data Center instance is required (Data Center license needed):
JIRA_E2E_HOST=http://localhost:8080 \
JIRA_E2E_EMAIL=admin \
JIRA_E2E_TOKEN=mytoken \
JIRA_E2E_PROJECT=TST \
All e2e tests tag created issues with [e2e-auto] for easy cleanup.
CI
GitHub Actions runs fmt → clippy → nextest on Ubuntu and macOS for every
push and pull request. The workflow is at .github/workflows/ci.yml.
License
MIT