Android development harness · Claude Code
A harness for Android development, run by agents.
applepi runs Claude Code against your tickets — each one in its own git worktree, several running at once — and shows you all of it from a single terminal pane. You step in only when a ticket needs you.
↑ the actual pie control pane — six tickets, six worktrees, running in parallel.
Get started
Install, point it at a repo, run a ticket.
macOS and Linux. Windows isn't supported.
$curl -fsSL https://raw.githubusercontent.com/andresuarezz26/pie/main/install.sh | bashFour things it expects to find:
| Prerequisite | Install | Check |
|---|---|---|
| Claude Code, signed in | claude.ai/download, then run claude once to log in | claude --version |
git | Preinstalled on macOS; apt install git / git-scm.com on Linux | git --version |
gh (GitHub CLI) | brew install gh, or see cli.github.com — then gh auth login | gh auth status |
| Android Studio | brew install --cask android-studio, or developer.android.com/studio | pie doctor |
Android Studio only matters once a ticket needs an emulator — skip it to start.
- 1Write a ticket.
applepi takes tickets as markdown files — the filename becomes the ticket id (
first-ticket.md→FIRST-TICKET). - 2Run it safely.
pie run first-ticket.md --dry-run --review-plan—--dry-runskips push and PR;--review-planstops before any code is written; the work happens in~/.pie/worktrees, never your own checkout. - 3Open the control pane.
pie— approve the plan and watch the ticket move to READY FOR REVIEW. - 4Do it for real.
Drop
--dry-runto open an actual pull request. It always stops at review — applepi never merges anything.
How it works
Each ticket runs in its own worktree.
Point applepi at a ticket and it plans the change, writes it, and verifies it against your project's own build and tests — booting the emulator if the ticket needs one — before opening a Pull Request. Several tickets run at once, each isolated in its own git worktree, and nothing merges without you.
Plans the change
Reads the ticket and drafts a plan you can pause on and approve.
Writes it
Implements the change inside an isolated git worktree, never your checkout.
Verifies it
Runs your project's own build and tests — booting the emulator if needed.
Opens a PR
Pushes a branch and opens a pull request. Nothing merges without you.
Day to day
Bare pie is the control pane.
It's where most of the work happens: write or paste a ticket, confirm its id and branch name, press enter. Queue several and they run in parallel.
| Key | Action |
|---|---|
| ↑↓ | Move |
| enter | Choose — on a paused ticket, read its plan |
| n | Start new ticket(s) |
| a | Answer a blocked ticket |
| o | Open the worktree in Android Studio |
| c | Open the session in Claude Code |
| R | Resume from the last stage |
| x | Stop and clean up |
| : | Command palette — everything above, plus doctor, config, and the daemon |
Everything above is also available straight from the shell:
pie startis a janitor, not a scheduler — it reclaims worktrees once their PRs are merged or closed, and shuts the emulator down when it's been idle. Tickets are always started by you, from pie run or the TUI.
Every pie run flag
| Flag | What it does |
|---|---|
--dry-run | Everything except git push and the PR. Try this first |
--review-plan | Pause after planning so you can approve or redirect before any code is written |
--branch <name> | Exact branch name for the PR, overriding the config pattern. One ticket at a time |
--base <ref> | Base branch — or another ticket's id — to stack on. The PR targets it |
--repo <path> | Which configured repo to use. Defaults to the first one |
--resume | Keep your manual fixes in the existing worktree, re-run verification, then PR |
--ship | Skip verification entirely: commit, push, and PR from your manual fix |
--from-plan | Skip planning and implement from the plan.json already in the worktree |
--local | Take the ticket inline from --title/--desc instead of a markdown file |
--title / --desc | The ticket summary and body, with --local |
--splash | Replay the title screen first. Works on any command |
--base accepts a ticket id as well as a branch name, so pie run second.md --base FIRST-TICKET builds on the branch FIRST-TICKET created and opens its PR against it. A plain re-run of a stacked ticket keeps its base rather than silently resetting to the default branch.
Cost, telemetry, and privacy
Runs on the subscription you already pay for.
applepi runs on your existing Claude Code subscription or API key — no separate account, no markup. Each ticket costs a full working session's worth of tokens, so five parallel tickets is roughly five concurrent sessions. Start with one.
Telemetry is opt-in, asked once during pie init. When enabled it sends three events — run_started, run_completed, tui_opened — carrying a randomly generated device id, your OS and architecture, the applepi version, and for a completed run its outcome state, duration, and whether it errored. No ticket content, no file paths, no repo or branch names, no code. Turn it off any time with telemetry_enabled = false in ~/.pie/config.toml.
Troubleshooting
Most things are one command away.
| Symptom | Fix |
|---|---|
pie: command not found | ~/.local/bin isn't on your PATH. The installer prints the line to add |
| A run fails immediately | pie doctor — it's almost always gh or claude auth |
| A ticket is stuck or vanished | pie logs <TICKET> has the full session. pie status shows every state |
| A ticket landed in NEEDS YOU | Read the reason in the TUI, fix it in ~/.pie/worktrees/<TICKET>, then pie run <TICKET> --resume |
| Verification skips instrumented tests | pie doctor — avd_name is probably unset, so it fell back to unit tests |
| A worktree is wedged | Press x in the TUI to stop and clean up, then re-run |
go.mod requires go >= 1.26.2 | Building from source with an older Go: prefix with GOTOOLCHAIN=auto |