The thing I keep telling people about SessionForge is that I didn't set out to build a product. I set out to solve a deeply specific personal problem: I wanted to run Claude Code on my desktop while I was away from my desk.
Before SessionForge existed, the workflow looked like this:
It worked. I was literally controlling Claude Code sessions from my phone — starting tasks, checking output, redirecting when something went sideways. But "worked" is a generous term. It was fragile, manual, and required knowing exactly which screen session was running what.
The cognitive overhead of managing it was starting to eat into the time I was saving by running things remotely.
The first real version was something I called Claude Remote Manager. It was a bash script that wrapped screen sessions and a small local web server that showed session status. Nothing fancy — it was a personal tool, built for exactly one person's workflow.
The web server ran on the same machine as Claude Code. I'd tunnel to it over Tailscale and get a rough list of active sessions: which directory they were running in, whether they were still alive, and a log tail. I could send input through a form. It was ugly but it worked.
"It worked — I was controlling from my phone yesterday." That was the validation moment. Not a polished demo, not a customer interview — just the thing actually functioning the way I needed it to.
The problem that pushed this from personal tool to product was multi-machine. I had a desktop, a cloud VM for long-running tasks, and occasionally a client's machine I was working on. Managing three separate Tailscale connections, three separate SSH sessions, three separate web servers — the cognitive load was back.
What I actually wanted was a single dashboard. Log in once, see all machines, click into any session from any of them. The kind of thing that shouldn't require three different tools and a mental map of IP addresses.
That's when the architecture shifted from "bash scripts wrapping screen" to something real.
The agent is the core of how SessionForge works. It's a single static binary — no dependencies, no runtime — that runs on the machine where your sessions live. It handles:
Writing it in Go was the obvious choice: cross-platform, single binary, good PTY support, fast. The agent compiles for Linux amd64/arm64, macOS Intel/Apple Silicon, and Windows x64. You run one install command and it's there on startup forever after.
The web dashboard is what the original personal tool was trying to be. It's a Next.js app running on Cloud Run with a real-time view of every registered machine. You can see CPU, memory, and session count at a glance. Click into a machine and you get its sessions. Click into a session and you get xterm.js — a full terminal in the browser, WebSocket-connected to the actual PTY on the remote machine.
Start a session, stop a session, send input — all from a browser. From a phone if you want. The Tailscale requirement is gone because the agent handles the connection.
The product that grew out of that personal tool does a few things:
Products built from genuine personal pain tend to have a specific quality: the defaults are right. You don't have to configure it to work the way a developer actually works — it already does, because the person who built it was scratching their own itch.
I built the thing I wanted to exist. If you're running Claude Code on more than one machine, or if you've ever wanted to check on a long-running session from your couch, that's exactly the use case SessionForge is built for.
Free plan, no credit card. Install the agent in under a minute. The dashboard will make sense immediately.