Skip to content

Getting started

Run hangar on a laptop in five minutes and give it a first task. This is the one Quickstart; the README repeats its five commands. Concepts explains the words (environment, harness, sandbox, session, job) and what hangar gives you. The changelog says what each release added.

Quickstart

Five minutes on a laptop. You need Docker (Docker Desktop, OrbStack or Colima on macOS) and uv (Python 3.12+ is managed by uv).

git clone https://github.com/Sean-Koval/hangar.git && cd hangar
uv sync --all-extras
uv run hangar up        # server, CLI login, the claude-python environment, MCP clients
uv run hangar cred add claude-api --harness claude-code --kind api_key --file anthropic-key.txt
uv run hangar doctor    # every check passes, or names its fix

hangar up does five things:

  1. checks that Docker is running;
  2. starts the control plane in the background (log: ~/.hangar/server.log);
  3. logs the CLI in;
  4. builds the claude-python environment (the first build downloads tools, so allow a few minutes);
  5. offers to connect each MCP client it finds.

Running it again is safe: it reuses the running server, the saved login and the built images. --env NAME builds other environments, --no-build skips building, and --connect codex connects a client without asking. hangar down stops the server.

Open the console at localhost:8787 to see your fleet, credentials, environments and live terminals (the web console). Local state is in ~/.hangar. If a doctor check fails, follow its fix; uv run hangar doctor --fix applies the supported repairs.

To look around first without Docker or a key, run the demo hangar the front page's recording uses: uv run python docs/assets/front/demo.py. It serves the console on :8787 and prints its token. Then run uv run python docs/assets/front/demo.py ticket in another terminal to label issue #42.

Credentials

Use Credentials in the console, or store a key from the CLI as above. Use an API key (an Anthropic Console key, an OpenAI project key, a Claude Team or Enterprise key). Set a spend limit on it in the vendor's console; hangar's own job and daily budgets cap spend inside hangar. For Codex, and for private repositories:

uv run hangar cred add codex-api --harness codex --kind api_key --file openai-key.txt
uv run hangar env build codex-node
uv run hangar cred add gh --harness git --kind git_token --value "$(gh auth token)"

Choose the credential when creating a sandbox, or list its name in your environment's credentials field. Storing a key alone does not attach it to every sandbox.

Jobs, schedules, webhooks and experiments run on API keys only. A personal subscription login (Claude Pro or Max, a ChatGPT sign-in) is for your own interactive sessions, with a warning: see subscription logins.

Connect your client

If hangar up did not connect your client, run uv run hangar connect claude-code (or codex, cursor, vscode, gemini, claude-desktop). It adds hangar to the client's own config file, next to your other servers. Its fresh token can reach the MCP endpoints and nothing else:

  • hangar (/mcp: jobs, sessions, schedules);
  • for Claude Code and Codex, hangar-sandbox (/mcp/sandbox: create_sandbox, exec, files, terminals; the two servers).

Start a new client session so it reads the updated configuration. hangar connect --list shows what's connected; connecting clients covers all options, remote connections and OAuth.

First task

In your connected MCP client, ask:

Use hangar to create a claude-python sandbox for https://github.com/YOUR-USER/YOUR-REPO.git. Use the claude-api credential and a new work branch. Run Claude Code to explain the project structure and how to run its tests. Report the sandbox name and findings.

Replace the repository URL with your own. Start with a public repo, or add a Git credential for private repository access. The same from the CLI:

uv run hangar sb create claude-python \
  --name first-task \
  --repo https://github.com/YOUR-USER/YOUR-REPO.git \
  --work-branch hangar/first-task \
  --cred claude-api

uv run hangar sb agent first-task \
  "Explain the project structure and how to run its tests."

Open the sandbox in the console to follow the work in its live terminal. When you finish reviewing it, remove it with uv run hangar sb rm first-task. For Codex, use codex-node and --cred codex-api instead.

Next steps

To Read
Delegate from your client with the skill, run parallel attempts, write your own environment After the first task
Run it on GKE, then for a team From a laptop to GKE and a team
Choose where sandboxes run, and see what has been proven live Where it runs
Change settings, or work on hangar itself Configuration and development
Connect Codex, Claude Code, Cursor or another client Connecting clients · Using MCP
Hand a task to a cloud agent and get a PR back Jobs
Keep working with an agent across days Sessions
Write an environment for your repo Environments
Take work from GitHub, Jira or Slack Jobs: trigger from GitHub · Intake · Slack
Let an approval land the PR Landing
Put a team on it, repo by repo The onboarding runbook
Upgrade a running hangar Upgrading
Run it day to day, and when something breaks Runbooks · Troubleshooting

What's new

Newest first, up to main today. Each release's page says what changes for a running hangar (release notes); the changelog lists every PR.

Release What it brings
main, unreleased (KAN-74 to KAN-232, up to #424) Every job runs on an API key and enforced intake. GKE egress is an allowlist. Tower can govern approvals and Claude Code's tool calls. The AI review keeps only confirmed findings. The A2A endpoint, the E2B-compatible API, the GitHub Projects door and the gemini harness are removed.
v0.2.0: adopt & capture (#133–#189) The team workflow. Jira "Ready for agent" is the default door, and the inbox reaches you in Slack. The review cap, steer classes, weekly metrics and the Friday review keep the loop honest. Every run is captured to the outbox for flightdeck.
v0.2.0: the safe release (#120–#132) Secure intake by default: the git gateway and egress proxy for jobs from trackers, and API keys for automated work.
v0.2.0: the team release (#75–#117) One hangar for six: people and their tokens, repo policies, budgets, Jira intake, approvals that land the PR, environments that live in the repo.
The overnight stack (#48–#69) Live turns with steering and approvals, durable sessions, the uid split, the git gateway and hangar up.

Moved from this page

Section Now on
Use the hangar skill After the first task
Parallel attempts After the first task
Take work from GitHub After the first task
Your own environment After the first task
Everyday commands After the first task
Production (GKE) From a laptop to GKE and a team
A team on one hangar From a laptop to GKE and a team
Where it runs Where it runs
Known limits Where it runs: known limits
Configuration Configuration and development
Development Configuration and development
MCP tools Using MCP: the tools
Environment specs Environments: environment specs