Walk away mid-run. Pick it up on your phone.

Sudo Dock is a local daemon that owns your agent CLI sessions as persistent tabs. Any browser on your network attaches to the exact same live state — laptop, tablet, phone. No SSH app, no tmux, no reattaching by hand.

claude
codex
gemini
pi / omp
grok
aider
local models
any terminal tool

It doesn't drive your CLI tools or own your conversations. It attaches to sessions the vendor tool already owns, reading the same session files Claude Code, Codex, and Gemini already write to disk, and resuming with each tool's own --resume. Uninstall Sudo Dock and every session still opens fine without it.

Want a second pair of eyes? Send someone a link, read a six-digit PIN out loud, and they're in that one chat from their own browser. Nothing installed, nothing else exposed →

no public build yet — I'm setting up early users by hand

Sudo Dock in a desktop browser: a sidebar of three chats in a sample workspace, one marked working and one done, and the open chat showing a completed Claude Code turn with the composer below it. — The same chat on desktop and on a phone. Both are browser captures of the real app on a sample workspace with example data.

The same chat attached from a phone browser, with the mobile composer and Respawn control. — The same chat on desktop and on a phone. Both are browser captures of the real app on a sample workspace with example data.

Guest access

Hand someone a seat without giving them anything.

You're deep in a session and want a second pair of eyes. From the chat menu you create a one-use link and a six-digit PIN. They open it in their own browser and they're in the same live conversation — nothing installed, no account, no access to your machine.

They see that one chat. Not your sidebar, not your projects, not your terminal, not a filesystem path, not a byte of PTY output from anything else. You pick read-only or can-ask-questions and the daemon enforces it — a read-only guest has no composer, and the server refuses the send even if they forge one. Their messages arrive attributed.

Invite several people to the same chat and each one is independent — own name, own mode, own expiry. Extend one, revoke another, and nobody else's session drops. Sessions you can hand out, seat by seat.

— built it to pull my son into a live session to help. No install on his end, just a URL and a PIN read out loud.

What's actually built

Seven things that work today, and one that's early.

Everything here is on current main and in daily use. Where a tool only exposes part of a thing, the card says so.

anything that runs in a terminal: If it runs in a terminal, it opens as a tab — your own scripts, a local-model CLI, a tool I've never heard of, a tool that competes with this one. No adapter is required to run something. Adapters are enrichment on top: Claude Code, Codex, Gemini CLI, Pi / oh-my-pi and Grok get auto-named topics, context usage, and a working / blocked / idle / complete state where the tool exposes enough to tell.
sessions that outlive the daemon: PTYs die when the daemon restarts; your conversations don't. Sudo Dock relaunches each tab with the tool's own --resume <id> — exact for Claude Code and Pi/omp, best-effort for Codex and Gemini — and refuses visibly rather than silently starting a fresh session if a resume isn't safe. Mark a tab keep-alive and it comes back on its own after a restart.
any browser is a full client: The daemon binds loopback by default; pair a second device with a six-digit PIN and it attaches over WebSocket to the same tabs. Several browsers can watch and drive one session at once — close one, the tab keeps running on the daemon. Phone push tells you when a background chat finishes, even with Sudo Dock closed.
scoped guest access: That's your own devices. For someone else's, a chat menu makes a one-use link plus a six-digit PIN that grants 24 hours on that one chat only — no sidebar, no projects, no terminal, no filesystem paths. Read-only or can-ask-questions, daemon-enforced; extend or revoke each guest independently.
cross-tool session history: Sudo Dock indexes the session files Claude Code, Codex, Gemini and Pi/omp already write, plus import-only history from Cursor agent and Claude Desktop, so past work — even sessions started before Sudo Dock existed — shows up in "Resume from history."
split panes + a command palette: Tile several tabs side by side and every visible pane streams live, not just the focused one. Cmd+K searches live tabs, projects, imported sessions and pull requests from anywhere.
a control socket for your own agents: A separate, bearer-token-authenticated API (control.v1) lists, spawns, feeds input to, and waits on tabs — with per-token scopes and grants. It ships as a WebSocket, a CLI (sudock control …) and an MCP server, so any harness that speaks MCP can seat one agent as a coordinator that dispatches work to the others.
group chat early: Several agent tabs merged into one routed conversation, addressed by @alias, with no message store of its own. Built and in use, still being reshaped from what a real session teaches.

Your machine. Your code. Your sessions.

The daemon runs where your work already lives. The PTYs are local, the session files are local, the git history is local. Sudo Dock is the browser-accessible layer in front of it — not a cloud dev host, and not a place your code goes. Remote access today is whatever you already run: your LAN, your Tailscale, your tunnel.

Why this exists

It started with a bad phone experience.

I kept wanting to check on long-running agent sessions from my phone — approve a command, read what an agent had done, nudge it and walk away again. The obvious answer was "just SSH in." SSHing into your machine from a phone is miserable: tiny keyboard, no real terminal, dropped connections, squinting at a session you can barely scroll.

So Sudo Dock is the thing I wanted instead. A daemon runs on the machine where the code, the git history, and the CLI agents already live. It owns the terminal sessions. Any browser — laptop, tablet, phone — attaches over a WebSocket and sees the exact same live state. Close the lid, pick up the phone, tap into the tab, and it's the session that never stopped running.

It's been my daily driver for months. Everything on this page is something I use, not something I plan.

Lately

It moves most days.

Straight from the commit log and the closed issues on main, so you can judge the pace rather than take my word for it.

Sep 23 Continue in… moves a chat to another harness, account and model with its context. One prompt can go to several agents or models at once, each in its own worktree. Phone push notifications when a background chat finishes, even with Sudo Dock closed.
Sep 23 Accounts. One quota page for every account and window, a weekly pace projection that says "runs out before reset," alerts when a running chat's account nears its limit, and Codex reset credits shown and redeemable per account.
Sep 23 Composer. Drafts survive a reload and the sidebar marks chats with unsent ones; big pastes fold into a chip; up-arrow recalls sent prompts. Custom snooze times, PR ↔ chat linking with PR search in Cmd+K, and non-ASCII input to Codex on Windows fixed.
Sep 22 Claude's model-scoped weekly limits are read hourly and launches are bound to them; the account picker is model-aware.
Sep 21 Hardening pass. Loopback trust withdrawn for forged forwarding hops and rebinding Hosts; anti-framing and nosniff headers on every response; schema snapshots before migrating and a refusal to run on a newer schema; daemon tests now typechecked and lint blocks floating promises.
Sep 19 Keep-alive tabs that come back after a daemon restart; move a running chat into a worktree; per-project loop settings with an acceptance gate on control spawns; wait --until done|pr-open on the control API; per-tab git facts and a branch diff view.

351 commits on main in the first three weeks of September, 289 of them not merges.

Where this is

One user so far. That's the honest number.

Sudo Dock works, and it's been carrying my own work for months — but it has had exactly one person's hands on it. A small friends-and-family pilot is being set up; nobody outside is on it yet. Before it goes anywhere public I want a few people running it on machines I didn't set up, hitting the things I can't hit alone. If that sounds like your kind of thing, there are two ways in.

you want to use it

You already run two or more agent CLIs on a workstation and leave sessions going. There's no public build yet, so I'll set you up by hand — a packaged build, and me on the other end of an email when something breaks.

Node 22+ on Linux, macOS, or Windows. Nothing leaves your machine.

you want to help build it

The most obvious surface is CLI adapters — teaching Sudo Dock to read a tool it doesn't know yet, against a small documented interface. Beyond that: mobile input, group-chat routing, and agents that drive other agents over the control API.

Code contributions open once a CLA is in place. Until then, tell me what you'd want to work on and I'll show you the code.

Status

0.8-era, active development. Expect rapid iteration, not a 1.0 stability promise.
AGPL-3.0-only. Self-hosting is free, forever. A commercial license exists for running a modified Sudo Dock as a closed network service.
Linux and macOS, native. Windows runs native via ConPTY, or inside WSL if that's where your CLI agents already live.
Source isn't public yet. It exposes a terminal on your machine, so the public cut gets done carefully and once. Ask and I'll walk you through the code.
Not accepting code PRs yet — a CLA needs to be in place first — but bug reports with clear repro steps are welcome, and so is telling me what problem you're hitting.