Claude Code Was Chained To My Mac. Now It Deploys Work From My Phone

Thursday morning, Strands Beach in Dana Point. I'm down there most Thursdays for a beach workout.

Sitting with a coffee afterward, I cracked something I'd been circling for weeks. My prospect definition was too wide, and I could finally name the exact signals that separate a company that looks like a buyer from one that actually is. That's the kind of idea that decides whether outreach lands or gets ignored.

The fix was a change to how my machine pulls and enriches prospect data. The catch is that the next batch builds itself against whichever definition is live when it runs. So a great idea on Thursday morning is worth nothing if it ships on Friday.

Before this, that's a note in my phone and a drive back to the office. Make the change, ship it, watch the next run pick it up. I've done that a hundred times.

Instead I described the change to my Claude Code session from my phone. It made the edit and opened a pull request. I read it, merged it, told my server to deploy, and watched the server confirm it was running the new code. The next batch used the new definition.

Then I stayed another hour.

Let me kill the obvious read

This is not a post about working from the beach. I work long hours, most of them at a desk, because that's where the hard work happens. The hour on the sand isn't the win.

The win is that the hour was mine to spend. For years the answer to "does this have to wait?" was decided by where my computer was, not by how important the thing was.

You already know you're chained to your computer. Everybody does. The part nobody argues with is the next one — that the chain is permanent, the unavoidable cost of running something real.

It isn't. It's a design decision, usually made by somebody who is not you, and it can be undone. This is how I undid mine.

Where this fits

Most of what my company does, it does without me. How the agents are organized, who reports to whom, how work moves through GitHub, how a shared wall keeps twenty of them out of each other's way — that's all written down in the other guides in this series. Read those and you can get a system running that ships its own code.

This one is the last mile. The moment something has to go live, and you're not at your desk, and you don't want the answer to be "drive back."

And this piece is the story, not the manual. If you want to build it rather than read about it, I wrote the whole thing down separately: Deploy From Your Phone: The Build — the prerequisites, the endpoint code itself, why each safety property is there, and how to prove it landed.

Why that used to be impossible

Two separate walls, and I'd been living with both.

The first: a desktop Claude Code session is pointed at a folder. That's not a detail, it's the whole product. It reads your files, runs your tests, watches your logs, because it's standing inside your repository on your computer. And a session standing in a folder on a Mac cannot leave that Mac. On earlier Thursdays I could see from the beach that a run had fired, and read the line proving it. I couldn't open the conversation, because from the beach there was no conversation to open. No update fixes that, because nothing is broken. It's just what the words mean.

The second wall was worse, and older. Shipping anything to production meant an SSH from that same Mac, because that's where my server's key lived. So the system could do the work, review it, and approve it — and then stop, and wait for me to physically walk to a desk.

"Ship it" quietly meant "be at that desk."

flowchart LR
  phone["my phone"] -. no way in .-> session["Claude Code session<br/>lives in a folder"]
  session --> mac["the Mac in my office<br/>holds the only server key"]
  mac -->|SSH| box["the server that<br/>runs my company"]

Nobody works here but me. No employees, no contractors. The work gets done by agents I built, running on a server I own, and the whole thesis of a one-person company is that the business keeps moving when the person stops. I'd built most of that and then discovered it still required me to be in one particular room.

In a one-person company, you are the only ceiling. Every system you build to take work off you tends to hand something back — a step only you can approve, a tool only you can reach, a room only you can be in.

The two fixes I didn't take

Wait for the app to change. Apps change, apps change back, and you spend the interval organizing your life around somebody else's release notes. I've watched businesses do this with their CRM, their booking tool, their ad platform. They all call it temporary.

Remote into the Mac from my phone. This would have worked. It would also have meant the way I run my company is a remote-desktop app, on top of a desktop app, on top of a laptop that has to stay awake in an empty office and never crash. Three things that can each change on a Tuesday.

Both are the same move: rent the freedom back. When there's one of you, that's a bad trade, because nobody covers for you when the rented thing breaks.

My company got a front door of its own

Here's the reframe, and it's the part worth stealing whether or not you write code.

I'd been treating my Mac as the way in. It was never the way in. It was a device that happened to hold a key. My company doesn't live on the Mac. It lives on a twelve-dollar-a-month DigitalOcean server that I own, and a server can have a front door of its own.

Three pieces. None of them depend on an app behaving.

One. The session moved to the cloud. Claude Code also runs as a cloud session, with no folder and no machine. That version shows up on my phone, in the desktop sidebar, and in a browser tab — one continuous conversation across all three, not three copies syncing. This half of the answer had been sitting there the whole time. I was using the version that's better at everything except leaving.

The same Claude Code session open on my desktop and on my phone — one conversation, not two copies syncing.

Same session, two devices. The sidebar is the whole company: one named session per agent.

One warning, because it was the original failure: don't create that session as a scheduled routine. Routine-spawned sessions are a different class and may never appear in your session list at all. Open a new session and point it at your repo, by hand, once.

Two. The box updates itself. My server already held a read-only key to my own code, so it could always pull its own updates. It just had nothing to tell it when. Now it has exactly one locked endpoint. Knock with the right credential and the box fetches the approved code, snapshots its own database, installs, migrates, and restarts its services. No Mac in the path. No server key on the device in my hand.

Three. Proof is a measurement. There's a second address, public and needing no password, that answers one question: what code are you running right now. After a deploy you read it until it says the version you approved. Not a summary, not a promise — the running process, asked directly.

flowchart LR
  phone["my phone"] --> cloud["Claude Code cloud session<br/>no folder, no machine"]
  cloud -->|approve + merge| gh["GitHub"]
  cloud -->|"knock: deploy"| box["the server<br/>pulls its own code"]
  gh -. read-only key .-> box
  box -->|"what am I running?"| phone

Review from anywhere, approve from anywhere, ship from anywhere, and verify by reading the machine instead of believing the messenger.

A door that ships code deserves scrutiny

Anything that can change production from the open internet should make you nervous. Here's how nervous I was.

The door has its own key and that key does one job. It can ship the approved main line and nothing else. It isn't my dashboard login and it isn't my database password. If it leaked, the worst anyone could do is redeploy code that's already public. It rotates in one command and breaks nothing.

The caller chooses nothing. The request body is thrown away unread. No branch, no path, no options. An endpoint that ships whatever the caller names is an endpoint that runs a stranger's code as root on your server.

Missing means no. If the credential is absent entirely, nobody is authorized rather than everybody. Security mistakes have a direction, and that's the direction this one has to fail in.

The box keeps its own rails. If files on the server were edited by hand, the deploy fails loudly and changes nothing rather than quietly throwing that work away. The database is snapshotted before any migration runs. Two deploys can't overlap.

The detail I like most is smaller than any of those. The deploy restarts the very process that's answering the request, so the endpoint can't honestly say "done." It hands the job off and answers "started," and then you go read the other address to find out how it went.

The proof

I don't publish things I haven't run. Measured on the live box:

My Mac wasn't involved. No server key went near my phone. The deploy key never appeared in the conversation at all, because the box reads its own.

Build it yourself

Everything above is in production on my box right now, and none of it is complicated. It is one route, one narrow key, one update script and one public endpoint that answers a single question.

I wrote the build up in full, with the code: Deploy From Your Phone: The Build. It covers what you need before you start, the endpoint and each of its rails, where every secret lives, the checks that tell you it actually works, and the two DNS traps that look like server faults and are not.

The part that's actually about your business

I've been describing a server. You may not have one and may never want one. The three principles underneath don't care, and they matter most to the smallest companies, because a small company has nobody to cover for it.

1. Own the door, not just the room

Every business runs on borrowed doors. Your CRM's mobile app. Your scheduler's dashboard. The platform your customers message you on. Each one is somebody else's entrance to your own company, and when it changes, your ability to operate changes with it — on their schedule, not yours.

The question isn't "is this tool any good." It's: if this vendor changed tomorrow, could I still reach my own business? Where the answer is no, that's a dependency, and the minimum is to know you have it before it moves.

2. Proof is a reading, not a report

The reason I let an agent ship code to my production server while I'm sitting on sand isn't that it tells me it worked. It's that I can ask the running system what version it's running, and that answer isn't a claim anybody made.

When you're one person you can't supervise anything. You can only verify it. "It's handled" is a report. "Here's the thing itself, go look" is a reading. Every process in your company you can't check by reading something real is a process running on faith. Some have earned it. Name the ones that haven't.

3. Write down what still needs you

I didn't take myself out of the loop. I wrote the loop down.

My system reviews, merges and ships approved work on its own, all day, without asking me. Four things stop it cold: anything that spends money, anything that changes how fast we email people, anything that publishes or sends in my name, and anything that deletes.

flowchart TB
  work["work finishes overnight"] --> gate{"does it touch money,<br/>send rate, publishing,<br/>or deletion?"}
  gate -->|no| ship["reviewed, merged, shipped<br/>without me"]
  gate -->|yes| me["waits for me"]

That list lives in a file inside the system it governs, so the same changes that update the business update the instructions. Not in a chat message and not in my head. Most companies keep their real operating rules in a document nobody opens plus a founder's memory, which is the same problem with better furniture.

That list is also the honest definition of what I'm building. A one-person company isn't one where nothing needs you. It's one where the things that need you are written down and short. Everything else moves without you.

What it can't do

The cloud session has no shell on my box. No logs, no database, no files. It knows exactly what the health address tells it and nothing more, and its standing order is to say so instead of guessing. It's specifically not allowed to tell me something is live because it called the endpoint. It has to go read.

That constraint is a feature. An assistant that reports success it didn't verify is worse than one that reports nothing, because you'll act on it.

Where this leaves me

Most days I'm still at the desk, by choice, working long hours on things that need long hours. But the change I made on that Thursday shipped from a phone, on hardware I own, through a door I built, with one narrow key and a written list of the decisions that are still mine.

I'm not chained to a computer anymore. I just use one, most of the time, because I want to.

That's the whole difference: a business that needs you in a room, versus a business that needs you on a question.