The cloud can have my code. It can't have my Claude.

Kaushik N — Wed, 16 Sep 2026 13:46:01 +0000

The Claude app can start a coding session from your phone. It spins up a cloud sandbox, clones your GitHub repo into it, and lets you work from anywhere. For a lot of people, that's everything they need.

It wasn't enough for me, and the reason turned into a project.

The setup that can't travel

Over the last few months I've customised Claude Code heavily. None of it is exotic, but it adds up:

Hooks: scripts that run automatically on events. Mine refuse a commit until the review steps have actually run.
Skills: written instructions for how I plan, review, test and ship.
A global CLAUDE.md: the rules I want followed in every project, rewritten every time something goes wrong.

All of that lives in my profile folder, not in any repository. I keep it out of GitHub on purpose, because it describes how I work and what I'm building.

A cloud sandbox gets a clone of my repo and stock Claude Code. Same model, much worse assistant. That's the whole pitch in one line: the cloud can have my code, but it can't have my Claude.

Claude Code's Remote Control already lets me continue a session on my PC from my phone. But someone has to start that session at the desk first. I wanted to start one from my phone, in whichever project I pick, with my whole setup loaded.

What I built

Claude Remote is a Claude Code plugin. Fittingly, it installs into the same setup it exists to protect. You add its marketplace and install it from inside Claude Code, with no separate download and no cloning. If you want to change how it works, you fork it.

Under the hood it's two small pieces:

A Node agent on my Windows PC. It has zero dependencies, runs as a scheduled task, and listens only on loopback.
A PWA on my phone. It lists my projects, starts a session when I tap one, and stops it when I tap stop.

The phone reaches the agent through tailscale serve, so it only works inside my private Tailscale network. There are no open ports, and every API call needs a token issued by a passcode. When I tap a project, a PowerShell launcher changes into that folder, activates its environment, and runs Claude Code with Remote Control on. The session appears in the Claude app's Code tab, and I drive it from there.

The PWA is deliberately not a terminal. It's a start button. The conversation happens in the Claude app, which already does that well.

One touch I like: if the project has a HANDOFF.md, a notes file I keep for where the work stands, the launcher passes a first prompt:

Read HANDOFF.md and give the opening report.

A session I start away from my desk opens by telling me where things are, instead of sitting silent waiting for input.

That created its own problem. A session could now start itself and begin working with nobody watching. So the opening report has to end as a proposal and wait for my go. The first thing I hear from a session should never be work that's already underway.

Four bugs that passed every test

The code was the easy part. What took the time was a series of bugs that looked fine from every angle a test could see.

1. One flag silently broke Remote Control

My desk setup launches Claude Code with a --channels flag for a messaging plugin. I carried it over to the launcher.

The session started perfectly. Right window title, interface drawn, ready to work. But Remote Control sat on "connecting" forever, and the session never appeared in the Code tab. From the phone, it looked like nothing had happened.

Removing that one flag fixed it in seconds. Two experimental input channels were competing for the same session.

No test could have caught this. The process was healthy, and the only symptom was a row missing from an app on my phone. It took a person looking at the screen. Now, any change to the launch arguments means checking the app again, by hand.

2. A reviewer's fix would have broken every Python project

To activate a Python virtual environment, the launcher adds the venv's Scripts folder to the front of PATH. A review pointed out that a ; in the project path would split that entry, and suggested quoting it.

Sensible advice, but wrong here. PowerShell's command resolution doesn't honour quotes inside a PATH entry. With the quoted version, python resolved to the system interpreter, while VIRTUAL_ENV claimed the venv was active. Every venv project would have launched outside its venv, and nothing would have looked wrong.

The whole test suite stayed green, because the tests used a synthetic venv. They proved python.exe existed in the right place, never that it resolved. I only caught it by running the real launcher against a real venv and asking which python came back.

A ; in the path is now refused with a clear message instead of quoted around.

3. `conda activate` failing doesn't throw

For conda projects, the launcher reads the environment name from environment.yml and runs conda activate. I wrapped it in a try/catch.

That catches nothing useful. In PowerShell, a native command exiting non-zero isn't an exception, even with $ErrorActionPreference = 'Stop'. When the environment doesn't exist, which is the most likely failure, conda prints an error and carries on. A cloned repo naming an environment you don't have would have launched a healthy-looking session sitting in base.

The fix checks the result, not the exception. After activating, the launcher compares CONDA_DEFAULT_ENV against the name it asked for, and refuses the launch if they differ. The try/catch stays too, because a command-resolution failure does throw. That distinction is the entire guard.

4. Activating a venv let a repo choose which Claude to run

Adding the venv's Scripts folder to PATH had a second consequence. The launcher started Claude Code by name, so the name was looked up through the new PATH. A cloned repo carrying its own claude.cmd in its venv would have had that file run instead, with my full user permissions, the moment I tapped the project.

The fix resolves Claude Code to an absolute path before the venv touches PATH, so the project never gets a say in which executable starts.

The state I deleted

Early on, a broken environment didn't stop the launch. The launcher recorded the error and started the session anyway, reasoning that a running session was better than none.

That produced a session that was alive and wrong at the same time. I designed five different ways to show "running, but in the wrong environment" on a phone screen, and every one was confusing. A condition that persists doesn't fit in the same banner as a one-off message.

In the end I deleted the state. A broken environment now stops the launch, and the phone shows why. A clear failure beats a session that quietly works in the wrong place.

What I took away

Green tests prove what the tests can see. Three of these four bugs lived at a layer the tests never touched: a phone screen, command resolution, an exit code.
Run the real thing. A synthetic fixture proves a file exists. Only the real launcher proves it works.
Alive but wrong is worse than failed. If the tool can't do the job properly, it should say so and stop.

Claude Remote is Windows only and not public yet. When it is, it will be a plugin you can install from inside Claude Code, and a repo you can fork if you want it to work differently. Until then, if you keep your Claude Code setup out of your repos too, I'd like to hear how you use it away from your desk.

If you want to follow along, I'm on GitHub: https://github.com/MrTig-afk

DEV Community: Kaushik N