If you use Claude Code seriously, you've hit this: you start a long task, close your laptop to go somewhere, and come back to discover the session is dead. Or you want to check on something from your phone and there's no clean way to do it. Or you have a powerful desktop you want to offload work to from a slower laptop.
This post is a practical guide to setting up Claude Code on a remote machine managed by SessionForge, so sessions persist across device switches, you can monitor and interact from anywhere, and you never lose context because you closed a lid.
The setup has three pieces:
When you start a Claude Code session through SessionForge, it's running as a managed PTY on the host machine. Your browser connects to it via WebSocket through the relay. If you close the browser, the session keeps running. If you close your laptop, the session keeps running. You reconnect from any device and you're back in the same session.
On the machine where you want Claude Code to run, install the agent. One command:
curl -fsSL https://sessionforge.dev/agent | bash -s -- --key YOUR_API_KEYGet your API key from the SessionForge dashboard under Settings → API Keys. The installer detects your platform (Linux, macOS, or Windows) and installs the appropriate binary, then sets it up as a system service so it starts automatically on reboot.
On Linux it registers with systemd:
sudo systemctl status sessionforge-agentOn macOS it registers with launchd. On Windows it registers as a Windows Service. In all cases, after installation the agent is running in the background and will restart itself if it crashes or if the machine reboots.
Within a few seconds of installation, the machine appears in your SessionForge dashboard. You'll see the hostname, operating system, architecture, and real-time status.
Before creating a session, confirm that Claude Code is installed and accessible on the host machine. If you're setting this up on a remote VM, SSH into it directly and check:
which claude
claude --versionClaude Code should be installed globally on the host. If you're installing it fresh:
npm install -g @anthropic-ai/claude-codeMake sure the Claude Code environment is configured — the ANTHROPIC_API_KEY environment variable should be set, or Claude Code should be authenticated via its interactive login flow. You can test this by running claude directly in a terminal on the host machine before routing anything through SessionForge.
In the SessionForge dashboard, navigate to your machine and click "New Session." You'll see a dialog with these fields:
claudeClick "Start Session." The agent spawns a PTY on the host machine running the command you specified in the working directory you specified. The web terminal in the dashboard connects to it immediately.
You now have a live Claude Code session running in your browser, connected to your host machine.
sessionforge run CommandIf you prefer to start sessions from the command line rather than the dashboard UI, the SessionForge CLI gives you the run command:
sessionforge run --machine my-desktop --name "refactor-auth" --cmd claude --dir /home/user/projects/myappThis creates a named session on the specified machine and returns a session URL you can open in any browser. Useful for scripting — start a session as part of a deployment workflow, or create sessions programmatically via the API.
The CLI is available via npm:
npm install -g @sessionforge/cliAuthenticate it once with sessionforge auth and it uses the same API key as the agent.
This is the part that changes the workflow. Once a session is running, it stays running regardless of whether you're connected to it. Reconnecting is just navigating to it.
From the dashboard: go to Sessions, find the session by name, click into it. The terminal reconnects and you see everything — the current state of Claude Code, all the output since you were last there, and a live connection for new input.
From your phone: same thing. sessionforge.dev is mobile-responsive. The xterm.js terminal works in a mobile browser — you can send input via the on-screen keyboard, see output, and monitor what Claude Code is doing. Not as ergonomic as a full keyboard but completely functional for checking in, approving a plan, or sending a quick instruction.
From a different machine: same URL, different device. Open the session, you're in.
Here's what a real day looks like with this setup:
Morning, at my desk: I start a Claude Code session on my desktop pointed at the project I'm working on. Give it a task — refactor this module, investigate this bug, write tests for this feature. Claude Code starts working.
I close my laptop and go somewhere. The session is still running on the desktop.
From wherever I am, I open the SessionForge dashboard on my phone or laptop. I navigate to the session and see what Claude Code has done. If it's waiting for input, I give it. If it's still working, I watch the output or close the browser and let it keep going.
Later: I'm back at my desk or on a different machine entirely. I reconnect to the session. The full context is there — everything Claude Code did, the current state, the conversation. I pick up exactly where things are.
The session accumulates context over its lifetime. You're not starting fresh with each reconnect. The conversation history that makes Claude Code useful on longer tasks — the understanding of the codebase, the decisions made earlier in the session — is all there.
On any real project you'll end up with multiple sessions. A naming convention helps:
auth-refactor, JIRA-12342026-03-26-api-docsinvestigate-perf-issue vs implement-perf-fixSessionForge shows all active sessions in a list view. Dead sessions (crashed or stopped) show a different status. You can see at a glance what's running, what finished, and how long each has been active.
Claude Code sessions end. Sometimes they complete the task. Sometimes they hit an error, run out of tokens, or get killed by the OS. SessionForge records the session exit and, on Pro and above, you can set a webhook to fire when a session stops unexpectedly.
Configure a webhook in Settings → Webhooks, point it at a Slack channel or PagerDuty endpoint, and set the event to session.stopped. You'll get a notification when something ends, with the session name, machine, and exit status. You can reconnect to the session history to see what was happening before it stopped.
This matters for long-running Claude Code tasks. If you start a multi-hour task and go to sleep, you want to know in the morning whether it finished cleanly or crashed partway through — not discover it when you check manually.
The before state: sessions tied to the device I was on, lost when the lid closed, no clean way to hand off between devices, no visibility from mobile.
The after state: sessions are first-class persistent objects. They run where the compute is, accessible from wherever I am. The friction of switching devices or locations dropped to near zero.
For any workflow where you're running Claude Code on tasks that take more than a few minutes, or where you want to use a powerful machine as your actual compute rather than your current device, this setup is worth the twenty minutes to put together.