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:
- checks that Docker is running;
- starts the control plane in the background (log:
~/.hangar/server.log); - logs the CLI in;
- builds the
claude-pythonenvironment (the first build downloads tools, so allow a few minutes); - 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 |