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

sudock is a local daemon that owns your agent CLI sessions as persistent tabs — Claude Code, Codex, Gemini CLI, Grok, Pi and oh-my-pi, or Aider, OpenCode, a local model behind Ollama, your own script. Anything that runs in a terminal. Any browser on your network attaches to the exact same live state — laptop, tablet, phone. No SSH app, no tmux, no reattaching by hand.

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 sudock and every session still opens fine without it.

And when you 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

The sudock desktop UI showing a Claude Code session mid-task on a Postgres 17 migration — a sidebar of projects and agent tabs on the left with live working, blocked, and idle states, and the running terminal on the right — with the same live session open in a phone browser in front, showing identical scrollback and status. — Same live session, two devices. A migration running on the workstation, attached from a phone with nothing installed on it.

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. One-use link, 24-hour grant, five failed PIN attempts and the invite burns.

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

Six things that work today, and one that's on the way.

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, API, or hook is required to run something. Adapters are enrichment on top of that floor: 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. Everything else still runs fine without one.
sessions that outlive the daemon: PTYs die when the daemon restarts; your conversations don't. sudock 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.
any browser is a full client: The daemon binds loopback by default; pair a second device with a 6-digit PIN and it attaches over WebSocket to the same tabs. Multiple browsers can watch and drive the same session at once — close one, the tab keeps running on the daemon.
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 without touching the others.
cross-tool session history: sudock 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 sudock 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, and imported sessions from anywhere.
a control socket for your own agents in progress: A separate, bearer-token-authenticated API can list, spawn, feed input to, and wait on tabs — the base for seating one agent as a coordinator that dispatches work to the others. A "group chat" surface that merges several tabs into one routed conversation is designed and partly built, not finished.

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. sudock 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 sudock 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, so you can judge the pace rather than take my word for it.

Aug 29 An MCP server, so any harness that speaks MCP gets orchestration hands on your tabs — plus per-token scopes and grants on every control verb, and leashes that hold a spawned tab that breaks them.
Aug 25 Scoped guest sharing: one-use link, six-digit PIN, 24-hour grant on a single chat. Then multiple independent guests per chat, each with their own mode, expiry and revoke.
Aug 23 Group chat — several agent tabs merged into one routed conversation, addressed by @alias, with no message storage of its own.
Aug 19 Sidebar snooze with live countdowns, and a pass over the PTY fan-out path to cut redundant per-chunk work.
Aug 16 Run-state detection for Cursor agent, Pi and omp from their spinners; /health now echoes the deployed build SHA so a remote restart is verifiable.

Where this is

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

sudock works, and it's been carrying my own work for months — but it has had exactly one person's hands on it. Before it goes anywhere public I want a small group of 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 20+ on Linux, macOS, or Windows. Nothing leaves your machine.

you want to help build it

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

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 sudock 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.