About Termdeck

I built this because I was tired of SSH-ing into my own computer.

Termdeck is made by one person. Every feature on the pricing page started as something that annoyed me at 1am: a tmux prefix key I fumbled, a run that finished four hours before I noticed, a VPN that dropped while I was on a train. This page is the honest version of where each of those went.

Who

One developer, three machines, no team

I go by XDope. I am a working developer, not a founder who discovered a market. Termdeck exists because I needed it on a Tuesday and nothing on my disk did the job. If you want the wider picture of what I build and write, that lives on my personal site: bhavikp.in.

There is no team behind this. The whole company is one person, a desktop, a Linux box on the LAN that does the heavy agent work, and a small production server that serves the site you are reading. That is the entire fleet, and it is also the reason the product looks the way it does. I was the first person who had to keep three machines' worth of coding agents straight in their head, and I lost that fight badly enough to write software about it.

Practically, being a one-person shop means two things. Support email goes to the person who wrote the code, so nobody has to translate your bug report twice. And there is no roadmap committee, so if something is broken and small, it is usually fixed the same day rather than filed.

How it started

The terminal was fine. Living in it was not.

My setup was normal and, I thought, reasonable. Work on the desktop. Run the long, expensive agent jobs on the Linux box because it had the RAM. Keep production on its own server, untouched. Three machines, three shells, and the whole day spent typing ssh at one of them.

It fell apart in the boring way things fall apart. I would start a refactor on the Linux box, walk away, come back an hour later and find the agent had been sitting on a permission prompt for fifty-eight of those sixty minutes, waiting for a keystroke I was never going to see because the window was behind a browser on a different machine. So I did what everyone does: I learned tmux.

tmux genuinely solved the first problem. Sessions stopped dying when my laptop lid closed. But it handed me a stack of new ones. I had to learn a prefix key and then relearn it every time I went a fortnight without detaching anything. Panes let me watch two agents at once, right up until there were five, at which point I was cycling through a grid squinting for the one with a blinking prompt. And there was no way, none at all, to be told anything. tmux has no notion of a notification. It cannot tap you on the shoulder. It will happily hold a finished run in a detached session for six hours and never say a word.

The last straw was reach. To touch the Linux box from anywhere but my desk I had to wire the whole thing up: an SSH key on every device, a private VPN so the box was addressable at all, dynamic DNS because the home IP moved, and a mobile SSH client that turned a coding agent into eighteen columns of wrapped text on a phone screen. I once spent a Sunday debugging my own VPN config instead of the bug I had actually sat down to fix. That was the afternoon Termdeck started.

So the design brief was short, and it was written entirely out of spite: I should be able to open a normal browser tab, on any device I own, and see every agent on every machine, and the ones that need me should come find me.

Origin stories

Every feature is a grudge I held long enough to fix

Switching servers all day

I counted it once: forty-something ssh invocations before lunch, just moving between the desktop, the Linux box and prod to check on things that were mostly fine. That became the fleet board. The landing screen shows every session on every connected machine at once, so "how is that run doing" costs a glance instead of a login.

tmux, and relearning tmux

I would go two weeks without detaching anything and then sit there pressing the wrong prefix key like a man trying keys on a door he owns. Termdeck keeps the session alive without asking you to learn a multiplexer: you close the tab, the run keeps going, you open it later and it is where you left it. Keep tmux for your shells; it is genuinely good at those.

Nothing ever told me anything

The fifty-eight-minute permission prompt is the reason push notifications were the second thing I built. Real notifications now fire from the machine itself, so they land on your phone with no browser open anywhere. Installed as a home-screen app, Termdeck can page you the moment a run blocks or finishes.

The Sunday I debugged my VPN

SSH keys on four devices, a private VPN, dynamic DNS renewals, and a mobile terminal client that made a diff look like ransom mail. All of it deleted. The agent you install dials out over a plain WebSocket, like a browser does. No inbound port, no forwarding rule, no VPN, nothing listening on your home network.

Approvals I could not read

A raw approval prompt in a pane tells you a tool wants to run and roughly nothing else, and answering it means being at that keyboard. Approvals became a real interface: what the agent wants, why, allow or deny, from your phone if that is where you are. It survives a refresh, because I lost one to a browser reload and swore at a wall.

Diffs as scrollback

Reviewing an agent's edits in a terminal means reading plus-and-minus lines the size of your thumbnail while scrollback eats the top of the file. Now every edit renders as a proper diff you can actually read, docked next to the conversation that produced it, and you can open the surrounding project files without leaving the page.

The session I forked in half

I once had the same chat open in a terminal and in an early build of this, typed into both, and produced two divergent histories of one conversation. Genuinely upsetting to untangle. Now a session already being driven by another process is view-only. You can watch it, you cannot fork it, and taking over is deliberate.

Three CLIs, three sets of habits

Claude Code, Codex and Grok all solve the same problem and none of them agree on anything: different flags, different transcript formats, different ideas about what a session is. Termdeck speaks all three and shows them in one interface, so choosing an engine is a dropdown on a new chat instead of a change of muscle memory.

Undo by git-stash roulette

When an agent went wrong across nine files, my recovery plan was stashing and hoping. The engines write a checkpoint on every single edit, which is far too granular to be useful, so Termdeck folds them into one restore point per prompt, parked right above the message that caused the damage. You roll back the instruction, not a file.

Watching a run go the wrong way

There is a specific helplessness in seeing an agent, four minutes into a ten-minute run, confidently start editing the wrong module. My only move was killing it and paying for the whole turn again. Now you can steer mid-run: type the correction, it goes in on the same open stream, and the agent adjusts without starting over.

Wi-Fi that killed a live run

Walking out of range used to end a turn, which is an expensive way to learn where your router's dead spots are. Runs now park on your machine when the connection drops. The work carries on locally, the output is buffered, and when you reconnect you re-attach to the same turn instead of a corpse. Deploys work the same way: a restart is a pause, not a loss.

Coding agents on a phone screen

An SSH client on a phone is a technically-correct answer that no one enjoys. Termdeck installs as an app on your home screen: readable transcripts, approve or deny with a thumb, push when something needs you. It is not meant for writing the prompt. It is meant for the nine times a day you just need to unblock something.

None of these were planned features. Every one of them is a thing that went wrong on my own machines first.

Where we are registered

Termdeck runs under Wyoming law

Termdeck is operated by a Wyoming limited liability company. The terms you agree to when you create an account, the way any dispute is handled, and the obligations owed to you as a customer are all governed by the laws of the State of Wyoming, and that stays true whichever country you happen to be connecting a machine from.

That was not an accident of paperwork. Wyoming passed the first LLC statute in the United States in 1977, and four decades later it still does the thing that mattered to me: it does not require member and manager names to be listed in the public record, and it has no state income tax to complicate a business this small. For a one-person company whose entire pitch is your code never leaves your machine, incorporating somewhere that treats privacy as the default rather than a paid upgrade was the only version that was internally consistent.

The practical shape of that promise is architectural, not legal. Your coding agent runs on your own hardware, signed in with your own subscription, and the transcript files it writes stay on that disk. Termdeck reads them through the agent you installed and paints them in your browser; it keeps no transcript of its own. There is no copy of your repository sitting on a server of mine to be leaked, lost, or handed over.

Questions about the entity, the governing law, or what is stored and where go to [email protected] and reach me, not a queue.

FAQ

The questions people actually ask

Who builds Termdeck?

One developer, working under the handle XDope. There is no team, no support tier and no sales department. The person who wrote the reconnect logic is the person who answers the email. You can read more about the human at bhavikp.in.

Why is Termdeck a Wyoming LLC?

Wyoming wrote the first LLC statute in the United States in 1977 and still keeps member and manager names out of the public filing. For a one-person company whose whole pitch is that your code stays on your machine, being registered somewhere that treats privacy as the default rather than a paid add-on was the consistent choice.

Whose law governs my account?

The State of Wyoming. The terms you agree to, the way disputes are handled and the obligations Termdeck owes you as a customer all sit under Wyoming law, and that stays true no matter which country you connect a machine from.

Does Termdeck store my code or my transcripts?

No. Your agent runs on your own machine against your own subscription, and the transcript files stay on that disk. Termdeck reads them through the agent you installed and renders them in your browser. There is no copy of your repository on our side to leak, subpoena or lose.

Do I need to open a port or run a VPN?

No. The agent you install dials out to Termdeck over an ordinary outbound WebSocket, the same way your browser reaches any website. Nothing listens for inbound connections, so there is no port to forward, no dynamic DNS to renew and no VPN to keep alive.

Is Termdeck self-hostable?

Not today. Termdeck is a hosted control plane plus a thin agent you run on your own hardware, and keeping that one shape is what lets a solo developer ship fixes to everybody on the same afternoon. The part that touches your code is the part that runs on your machine.

Built out of spite, maintained on purpose.

If any of that sounded like your week, try it.

Connect a machine, open a browser tab, and stop SSH-ing into your own computer.