bitbucket-cli

Drive Bitbucket from your terminal — built for coding agents.

bitbucket-cli lets coding agents (Claude Code and others) — and humans — review and drive Bitbucket pull requests from the command line: browse repositories and source files at any ref, read per-file diffs and diffstats, check mergeability and CI build status, post inline review comments, and bring a PR into your local git checkout. It speaks to both Bitbucket Cloud and Data Center / Server, returns agent-friendly JSON with structured errors, and ships a companion Skill that teaches an agent how to use it. Write commands support --dry-run, and destructive ones require --yes.

📖 Documentation site: https://angelmsger.github.io/bitbucket-cli/

• Cloud & Data Center — one flavor-agnostic client; the backend (Cloud REST 2.0 or Data Center / Server REST 1.0) is detected automatically.
• Agent-friendly — JSON output by default, structured errors with exit codes and recovery hints, and diffstat-first PR review (pr files + pr diff --path) so an agent spends minimal context.
• Full PR lifecycle — list, get, create, update, decline and merge pull requests; diff (whole or per-file), commits, activity timeline; approve / unapprove / request-changes. Every write supports --dry-run; destructive commands need --yes.
• PR review closure — pr status aggregates mergeability + conflicts + reviewer states + CI build status in one call; pr threads groups inline comments by file; pr fetch / pr checkout bridge the PR into your local git checkout (--exec to run).
• Source browsing at any ref — file list / file tree / file get (with optional --range L1:L2 line slicing) read repository contents at a branch, tag or commit — no local clone required.
• Flexible configuration — CLI flags, environment variables, a .env file, a YAML config file, or an interactive wizard; secrets stored in the OS keychain, with per-user DPAPI fallback on Windows and a 0600 fallback on macOS/Linux.
• Companion Skill — a bitbucket Skill, embedded in the binary, that guides coding agents through the CLI.

Install the CLI with npm, then take two short steps to finish setup — deploy the companion Skill, then (optionally) enable shell completion.

npm install -g @angelmsger/bitbucket-cli

npm downloads the prebuilt binary for your platform, verifies its SHA-256 checksum, and keeps upgrades one npm update -g @angelmsger/bitbucket-cli away.

go install github.com/angelmsger/bitbucket-cli/cmd/bitbucket-cli@latest   # go 1.24+
make install                                                              # from a source checkout

The bitbucket Skill is embedded in the binary; it teaches your coding agent (Claude Code, Codex, Cursor, Agents (shared), Gemini CLI, GitHub Copilot, OpenCode, Continue, Windsurf, Grok Build, Pi, Kilo Code, and Roo Code) how to drive the CLI. skill install probes for installed agents and installs into each one found:

bitbucket-cli skill install            # auto-detect; install for each agent found
bitbucket-cli skill install --agent codex
bitbucket-cli skill uninstall          # remove it again

Re-run it after upgrading the CLI to keep the Skill version-matched. Details, including the npx skills workflow, are in docs/installation.md.

bitbucket-cli completes subcommands and enum flag values. Load the completion script for your shell once:

source <(bitbucket-cli completion bash)                        # bash, current shell
bitbucket-cli completion zsh > "${fpath[1]}/_bitbucket-cli"    # zsh, persistent

fish, PowerShell and persistent setup are covered in docs/installation.md.

bitbucket-cli config init --pretty   # interactive TUI setup (recommended for humans)
bitbucket-cli doctor                 # verify configuration and connectivity
bitbucket-cli workspace list         # discover the workspaces / projects you can see
bitbucket-cli repo fork myws/upstream --into myws --name upstream-fork --dry-run

# Find what to review (cross-repo "PRs awaiting my review")
bitbucket-cli pr inbox --role reviewer                          # DC: dashboard call; Cloud: add --workspace
bitbucket-cli pr inbox --role author                            # PRs I authored

# Review a PR (diffstat-first → per-file diff → optional local fetch)
bitbucket-cli pr status myws/myrepo/42                          # mergeable? conflicts? CI? reviewers?
bitbucket-cli pr files  myws/myrepo/42                          # per-file diffstat, sorted by churn
bitbucket-cli pr diff   myws/myrepo/42 --path src/server.go     # single-file unified diff
bitbucket-cli pr fetch  myws/myrepo/42 --exec                   # bring the PR into ./refs/remotes/origin/pr/42

# Browse source at any ref — no clone required
bitbucket-cli file get  myws/myrepo --ref main --path src/server.go --range 80:120
bitbucket-cli file tree myws/myrepo --ref v1.2.3 --path src/ --depth 2

# Comment, approve, merge
bitbucket-cli pr threads      myws/myrepo/42
bitbucket-cli comment add --pr myws/myrepo/42 --inline src/server.go:88 \
    --content "Hoist this allocation out of the loop?"
bitbucket-cli pr approve myws/myrepo/42
bitbucket-cli pr merge   myws/myrepo/42 --strategy squash --yes

Settings resolve in precedence order (highest first): CLI flags → environment variables (BITBUCKET_*) → .env → ~/.angelmsger/bitbucket/config.yaml (legacy fallback ~/.bitbucket/config.yaml) → defaults. See .env.example for the full list. Secrets are stored in the OS keychain. If Windows Credential Manager is unavailable, the fallback is encrypted with per-user DPAPI; macOS/Linux retain the 0600 fallback. Secrets are never written to the config file.

In the default JSON output, list commands return a {items, next, has_more} envelope; pass --cursor with a prior page's next to read the following page, or --all to fetch every page. --format ndjson instead streams the items themselves, one JSON object per line. --fields paths are relative to each record, so use --fields id,title,repository rather than prefixing paths with items.. A nested projection such as --fields repository.workspace emits the literal key "repository.workspace"; select repository when downstream jq should retain normal .repository.workspace access.

A single config file can hold several Bitbucket servers as named contexts. Most users need only one and never see the concept — config init --pretty configures a default context and the flow is unchanged. To work with more than one server, re-run config init --pretty and pick Add a new context, then:

bitbucket-cli config get-contexts          # list contexts, current marked
bitbucket-cli config use-context prod      # switch the current context
bitbucket-cli --use-context prod pr list --repo prod-ws/api   # override for one command

BITBUCKET_CONTEXT overrides the current context via the environment. Legacy single-server config files are read unchanged.

Failures are JSON on stderr (stdout stays a clean data channel) and map to stable exit codes: 0 success, 2 usage, 3 config, 4 auth, 5 permission, 6 not found, 7 rate limit, 8 network, 9 server, 10 parse, 11 conflict. Each error carries next_steps naming the command to run next, and retryable to guide back-off.

The HTTP client that powers the CLI is published as a standalone Go package, so a GUI or other tool can drive Bitbucket directly — same normalized models, Cloud / Data Center flavor handling and structured errors, without shelling out to the binary.

import (
	"context"
	"net/http"
	"os"

	api "github.com/angelmsger/bitbucket-cli/pkg/apiclient"
	cerr "github.com/angelmsger/bitbucket-cli/pkg/errors"
	"github.com/angelmsger/bitbucket-cli/pkg/transport"
)

// Authentication is a transport.Decorator you supply — it sets the
// Authorization header on every request. PAT uses a Bearer token:
func bearer(token string) transport.Decorator {
	return func(r *http.Request) { r.Header.Set("Authorization", "Bearer "+token) }
}

ctx := context.Background()
client, flavor, err := api.Build(ctx, api.BuildParams{
	BaseURL:       "https://bitbucket.example.com",
	Flavor:        "auto", // "cloud" | "datacenter" | "auto"
	AuthDecorator: bearer(os.Getenv("BITBUCKET_PERSONAL_ACCESS_TOKEN")),
})
if err != nil { /* see error handling below */ }

me, err := client.CurrentUser(ctx)

Errors are *errors.CLIError with a stable Category and Code, so callers branch on failure kinds instead of parsing strings:

if ce := cerr.AsCLIError(err); ce != nil {
    // ce.Category, ce.Code, ce.Hint, ce.NextSteps, ce.HTTPStatus, ce.Retryable
}

These pkg/... packages primarily back this CLI and its companion Skill; their exported surface is treated as a stable contract. Read the package doc comment (go doc ./pkg/apiclient) before changing it.

make test       # unit + integration tests
make e2e        # build + run against an in-repo mock Bitbucket server
make e2e-live   # additionally run read-only checks against the real server
make lint       # gofmt + go vet
make docs       # regenerate the CLI reference under docs/cli/

The docs/cli/ reference is generated from the cobra command tree by cmd/gen-docs, so it always matches --help. After changing a command or flag, run make docs and commit the result — CI fails if it drifts.

See docs/technical-design.md for the architecture and internal/ package layout, docs/releasing.md for the release process, and CHANGELOG.md for the version history.

Part of a family of agent-facing CLIs — one skeleton, one set of conventions, all built for coding agents. Browse the full set at github.com/AngelMsger:

• confluence-cli — Confluence as a knowledge base
• bitbucket-cli — Bitbucket pull requests & code review (this project)
• openobserve-cli — OpenObserve logs, metrics & traces
• jenkins-cli — inspect Jenkins jobs & builds
• jira-cli — Jira issues & workflow transitions

Released under the MIT License.