What using it looks like
Write a task → get a worktree → an agent works in it → you watch → you review → it merges
Six steps. You write the first one and approve the last; the middle four happen on the board.
1. Write a task, pick who does it
You describe the work and choose the agent. Claude Code, Codex, Gemini, Cursor Agent, opencode
— or several at once, each in its own pane of the same task.
2. dev-3.0 builds the sandbox
A fresh git worktree off your base branch, a tmux session inside it, your per-project
setup script, and — if you asked for them — free ports reserved for that task's dev server.
Heavy directories like node_modules or .venv are copy-on-write cloned, so the sandbox costs
near-zero disk and appears instantly.
Nothing the agent does can collide with another task. That is the whole reason ten of them can
run at once.
3. Watch without opening anything
Hover a card and the live terminal comes to you. No clicking in, no losing your place on the
board.
The card also carries the state you actually need at a glance: which agent and model, priority,
memory use, a bell when the agent wants you, and a red badge when it asked a question.
4. Several agents on one task, side by side
Split panes in the same worktree — one writes, one reviews, one runs the tests. Or three
independent variants of the same task on separate branches when you want to see which
approach wins.
5. Read the diff before anyone merges it
The built-in review panel shows the whole branch diff with syntax highlighting, per-file read
state, and inline comments on any line range. When you are done, one click copies the review
back into the agent's terminal as a prompt.
Markdown, Mermaid and images render as a preview instead of raw diff lines, and the preview
reviews like the rest of the diff: select any text and comment on it. The comment lands on
the same source lines a gutter comment would, marks the block it belongs to, lists under the
file, and joins the same review export.
Not sure the diff is safe? Launch a pack of read-only bug hunters — several agents that
comb the same branch diff in parallel, each seeded to look somewhere different, and report only
what they can prove.
6. Ship
The agent opens the PR and enables auto-merge. The card then shows the PR number and live CI
state, so a red build finds you instead of you going looking for it.
What else is in there
Your whole day on one screen
Every project, every running agent, one Activity view.
One click away: what the fleet actually got done. Tasks shipped, lines changed, velocity,
completion rate, active-day streak and average task lifetime — each against last week.
Spaces, when one flat list of projects stops working
Group projects into Spaces — Client work, Products, Infra — and the dashboard groups
itself, with a rail that filters it down to one space. A project can sit in several spaces at
once; nothing moves on disk and every project keeps its own board. Define no spaces and the
dashboard is exactly the screen it was.
The board is yours to shape
Add your own columns — AI Review, PR Review, On Hold, whatever your pipeline actually is —
and attach an agent to a column so that dropping a card there starts the work. Drag a task
into AI Review and a reviewer agent spins up on its own.
It runs headless, and your phone is a client
dev3 remote
Serves the full UI to any browser over a Cloudflare tunnel, your LAN, or an SSH forward. Scan
the QR once and your phone stays connected for 8 hours. Same board, same terminals, same live
previews — on a dev box you never sit in front of.
Keyboard-first, because you switch tasks all day
⌘K jumps between projects, ⇧⌘P runs any action, ⌥Tab cycles live tasks with a preview of each.
A CLI the agents themselves use
dev3 is not a side door — it is how agents talk back to the board. They set the task overview,
leave notes for whoever picks the task up next, ping you when blocked, show you an image or an
interactive HTML report, start a peer task, or peek at another task's terminal without
disturbing it.
dev3 attention "Need a decision on the schema" # red badge on the card
dev3 show-image before.png --caption "the bug" # in-app image viewer
dev3 peek --task seq:1383 # read-only look at a peer's terminal
dev3 message --task seq:1383 --in 30m --subject "status check" "status?" # type into a live agent, now or later
dev3 doctor --worktrees --prune-orphans # reclaim disk from dead worktrees
An agent can hand you a document instead of scrollback
dev3 show-artifact report.html puts a self-contained interactive page into the task — charts,
filters, sortable tables, its own light/dark switch. It opens beside the terminal that produced
it, stays attached to the task, and downloads as a ZIP. No server, no upload, nothing external.
Your shell prompt, your style
Shell panes get a two-line prompt with the task number, project, worktree-relative path, git
changes and how long the last command took — and it sheds segments instead of wrapping when a pane
gets narrow. Settings → Terminal → Shell prompt offers twelve zsh styles, each previewed by real
zsh; copy any of them into your own and tweak it, or keep the prompt from your own .zshrc.
And the small things
Dark and light themes · a hand-tuned 16-color ANSI palette so agents look right in both ·
English / Russian / Spanish · one-click dev server per task with auto-assigned ports · labels
and full-text search · sparse checkout for monorepos · scheduled and recurring agent runs ·
drag-and-drop files and pasted screenshots straight into a prompt · multi-window, one per
monitor.
Why it works this way
AI writes the code now. It commits, opens PRs, reviews. Your job changed — from writing to
commanding a fleet of agents across more tasks and projects than any one head can hold. The
bottleneck moved: it's not your editor anymore, it's your focus. Everything above is built
around that. Two things we optimize for, above all:
1. Your speed — as one person.
dev-3.0 optimizes a single developer: you. The unit is always the individual, never the org.
It works fine on a team — but it's not a tool for managing other people; it's a tool for each
person to command their own fleet and hit their own top speed. Everyone focuses on themselves,
and the whole moves faster.
2. Beautiful, and built around you.
A cockpit you stare at all day should be fast, gorgeous, and keyboard-first — and it should bend
to your way of working, not force one on you. Great tooling doesn't just make you productive;
it makes the work fun again. We sweat the polish.
And what we refuse: dev-3.0 is not an IDE — and won't become one.
- The code is the agent's job. No embedded editor; one click to your real VS Code or Cursor
when you truly need it — and the goal is to need it less.
- Git is the agent's job too. No manual staging, no hand-written commits.
- Integrate through your agent. Claude Code, Codex & co. already speak MCP to Linear, Jira,
and the rest. dev-3.0 is the cockpit; your agent is the adapter.
Which is for you?
Other tools in this space are great — if you want to live in an editor. dev-3.0 makes a
different bet. Pick by your goal, not a feature checklist:
| If you want to… | Reach for… |
|---|
| Stay in an editor, hands on the code and git | an agent IDE |
| Buy a platform for a whole team (SSO, seats, audit) | a team orchestrator |
| Run a fleet of agents solo, at speed, without drowning | dev-3.0 |
What that buys you, concretely
| Situation | What dev-3.0 does about it |
|---|
| Five agents editing the same repo | Five worktrees. They physically cannot conflict |
| You have no idea which of three approaches is best | Run all three as variants of one task, compare the diffs, keep one |
| An agent stops and waits for you — and you don't notice | The card turns red and the bell rings; Has Questions is a column |
| Reviewing agent output in a terminal is miserable | Full diff viewer with inline comments, and the review goes back as a prompt |
| You left the laptop and the build is still running | dev3 remote, scan the QR, keep going from your phone |
| A long task finished hours ago and you forgot it existed | The card carries the agent-written overview and notes, not just a title |
| Three hundred old worktrees ate your SSD | dev3 doctor --worktrees shows exactly what is reclaimable, and only deletes on your say-so |
Quick start
📖 Tutorial — Your first task, screen by screen. The
guided tour dev-3.0 runs on its own first launch, written out with screenshots: describe a task, watch
an agent do it in its own worktree, read the diff, merge, close. Nothing to install to read it.
🤖 The fastest way — paste this into Claude Code, Codex, Gemini CLI, whatever you already
run:
Install dev-3.0 by following the guide at https://dev3.h0x91b.com/ai-install.txt
The agent reads the guide, detects your OS, and does the whole install itself.
macOS, by hand:
brew tap h0x91b/dev3
brew trust h0x91b/dev3 # newer Homebrew refuses untrusted third-party taps (skip on older brew)
brew install --cask dev3
If a macOS task terminal later loses access to a repository on Desktop (Operation not permitted,
or Git saying not a git repository), see this troubleshooting entry. Full Disk Access
is a broad, optional troubleshooting step, not an install requirement.
Linux (headless box, full UI in your browser):
brew tap h0x91b/dev3 && brew trust h0x91b/dev3 && brew install h0x91b/dev3/dev3
dev3 remote
Windows — download
stable-win-x64-dev-3.0.zip
(~121 MB), extract it, run bin\launcher.exe. Windows support is brand new and may still be
rough, and the build is unsigned at this time, so the first launch needs two clicks past a
SmartScreen warning.
Details: Install guide.
Then: add a project (point it at a git repo), press ⌘N, describe a task, pick an agent, hit
Run. That is the whole onboarding.
Prefer a direct .dmg, a CLI tarball without Homebrew, a systemd service, or a build from
source? → Install guide
Agents and platforms
| Runs today |
|---|
| Agents | Claude Code · Codex · Gemini CLI · Cursor Agent · opencode · any CLI tool you configure |
| Desktop | macOS — Apple Silicon and Intel. Windows x64 — brand new and may still be rough; attached to every release, unsigned at this time |
| Headless | Linux x64 and arm64 (dev3 CLI + browser UI) |
Claude Code and Codex additionally report their status back automatically through hooks; the
others do it through the installed dev3 skill. Session resume, system-prompt injection,
rate-limit tracking and skill directories differ per agent — the full grid is in
agent-support-matrix.md.
Documentation
| |
|---|
| Your first task | The guided first-run tour, screen by screen — the fastest way to see what using dev-3.0 feels like |
| Install guide | Every install path, tmux versions on Linux, cloud-VM caveats, build from source |
| Remote access | dev3 remote in depth — tunnels, systemd, sessions, exposed ports, phone notifications |
| Troubleshooting | dev3 doctor, disk reclamation, Full Disk Access (including task terminals that lose access to Desktop on macOS), terminal colors and agent themes |
| Keyboard shortcuts | The complete list, mirroring the in-app ⌘/ panel |
| Agent support matrix | What each agent supports, feature by feature |
| CLI exit codes | The dev3 exit-code contract, for scripting |
| Diagnostic logs | What is logged locally, for how long, and what is redacted |
| Contributing | Setup, the pre-PR checklist, and what review looks like here |
| AGENTS.md |
Telemetry
The app reports usage analytics so the project can see what is actually used:
| Channel | What it sends |
|---|
| Google Analytics 4 | App launch, version and build channel, OS and its major version, screen resolution, language, CPU architecture, how the app was installed, which screen you are on, a 10-minute heartbeat, agent launches, and unhandled errors. How many projects and tasks you have is sent only as a coarse bucket (6-15, 201-1000), and how long ago you installed dev3 only as an age band (day-0, week-03). Your country is derived from your computer's timezone — your IP address is never looked up and never sent as data, and no city or region is sent. Identified by a random per-install id. Project names, task titles and file paths are deliberately never sent, and no project or task identifier goes into the page address either. |
| PostHog | Task and project actions (created, moved, merged, pushed …) plus unhandled errors, under a random per-install id. Also delivers feature flags. Live in the official release builds; a build from source has no key and stays off. |
Neither channel sends your project names, task titles, file paths, prompts, diffs or terminal
output. Autocapture runs with element text and attributes masked, and paths are stripped out of
crash reports before they are sent — the local log file keeps the untouched text.
Turning it off
Any one of these switches off everything at once: no GA4 hits, no PostHog client, no crash
reports. Feature flags then fall back to their shipped defaults.
| How | Where | Takes effect |
|---|
| Settings → System → Telemetry | The toggle, in any released build | Switching off is immediate; switching back on needs a relaunch |
DEV3_TELEMETRY=off | The app's environment (false, 0 and no work the same way) | Next launch, and it locks the toggle off |
DO_NOT_TRACK=1 | The app's environment — the cross-vendor convention | Next launch, and it locks the toggle off |
VITE_TELEMETRY=off | A build from source; compiles the channels out entirely | Build time |
# For one launch, or add it to your shell profile for every launch
DEV3_TELEMETRY=off /Applications/dev-3.0.app/Contents/MacOS/dev-3.0
# Compile it out instead
echo 'VITE_TELEMETRY=off' >> .env && bun run build
An environment variable read from your shell profile requires Settings → System → Import shell
environment to be on (it is by default); a variable set on the launch command itself always
applies. An opted-out install also stops handing its per-install id to the renderer at all, so a
browser on the remote-access server cannot read it either.
The rules this project holds itself to
These are not aspirations — they are the constraints any change touching telemetry has to meet.
See AGENTS.md for the
contributor-facing version.
- Everything sent is anonymous, always. No project names, repo paths, task titles, branch
names, prompts, diffs, file contents, terminal output, or anything else that could identify you
or your customer. Only a random per-install id and coarse facts about the app itself.
- An opt-out is always respected, everywhere. One switch turns off every channel, with no
exception kept alive "just for crashes" or "just for feature flags".
- An opt-out works in a released binary. A switch that only exists when you rebuild from
source is not an opt-out.
- A channel that cannot be masked is not enabled. If a vendor feature would send visible text
or free-form strings we cannot redact, it stays off rather than shipping with a promise attached.
Development
bun install
bun run dev # Build + launch the app locally (no HMR)
bun run build # Staging build
bun run build:prod # Production build
bun run lint # TypeScript type-check
bun run test # Tests (fast subset; `bun run test:full` for CI parity)
Built on Electrobun (native webview, no Chromium) and
Bun, with React 19 + Tailwind in front, ghostty-web
for GPU-accelerated terminals, and tmux underneath.
Contributions welcome — start with CONTRIBUTING.md: setup, the rules PRs most
often bounce on, and what review looks like here. AGENTS.md is the deep reference
behind it — the architecture doc and the house rules in one file.
Star history
License
Apache 2.0 — © 2026 Arseny Pavlenko
