Running Claude Code on a Mac Mini: What Two Weeks Taught Me

There is a small computer in my house that works nights. It sits on my desk in my office, between my son’s Lego table and my guitars. It has no monitor, no keyboard anyone uses, and no idea what time it is in the way the rest of the house does. At 8:00 every morning it reads the newsletter’s overnight signups and drafts a welcome note to each new reader before I am up. On Friday at five it reads my week and writes a first pass of my hours. In between, it holds every Claude Code session I have open, so that when I close my laptop in one office and open it in another, nothing I was working on has noticed.

Two weeks ago today it became the only place my sessions run. Before that they ran on the laptop I carry, which meant they died every time the lid closed, which is several times a day. I wrote up the plan in August and bought the mini on September 22. What follows is where the setup stands, what it cost to learn, and what I would tell you if you are thinking about doing the same thing. The lessons are mostly not about the computer. They are about where you are standing when you try to fix something.

The thirty-second answer

Why the laptop could not be the host

I work out of several offices in a week, and I live in Claude Code, which is a terminal you talk to. A session there can run for hours: it reads a folder, builds a page, renders a film, waits for me to say yes to a command. On a laptop, every one of those sessions ends the moment I close the lid to drive across town.

The obvious fix is to keep the laptop awake, and it fails the first time you put the laptop in a bag. The next obvious fix is to run everything in the cloud, and for a lot of work that is right. But my sessions need things that only exist on a machine of mine: the fonts, the Dropbox folders, the video render pipeline, the connector to the newsletter platform, forty gigabytes of project folders with two years of context in them. A sandbox in someone else’s data center has none of that.

So the plan I wrote on August 26 had one core idea and a four-phase build: prove the routine on a host at home, move the code there, live it for two weeks, and only then buy a dedicated machine. The last phase was marked optional. It stopped being optional in about three weeks, which is faster than I expected and slower than I wanted.

What is on it now

The mini is an M6 with 32 gigabytes of memory and no monitor attached. It sits on the home Wi-Fi and never sleeps. Sleep is off, it restarts itself after a power cut, and disk encryption is off with automatic login on, so that if the power goes out at 3 a.m. the machine comes back up on its own and reopens every session without anyone touching it. It is reachable only over a private mesh network, nothing on the public internet.

The last row is the part that would have embarrassed me a year ago. I have never written code for a living. Every script on that machine was written in a Claude Code session, by me asking for a thing in plain sentences and reading what came back until it did what I meant.

What a day looks like

I open a terminal on the laptop and type one word. The cockpit appears: on the left, a narrow column with every session, its project, how much context it has used, which model it is on, and whether it is working, idle, or waiting for a human. On the right, whichever session I pick. I type a row number and the right pane switches. I type a project name and a brand-new chat opens in that folder. The overview never moves and never closes. That was the whole requirement, and it took a week to get right, which I will come back to.

The dashboard itself got its own guide in August, when it still ran on the laptop: How to manage multiple Claude Code sessions. What changed is where it lives. It now runs on the mini, next to the sessions, which turns out to be the only place it ever should have run.

Then I close the laptop and drive. The sessions keep going. At a red light I open the Claude app on my phone, and the same sessions are there, because each one was started with Remote Control on. If one of them is waiting on a yes, I can give it the yes from the car line at school. At the next office I open the laptop, type the one word again, and the cockpit comes back showing the session I was last in.

The lessons, in the order they cost me

Each of these took at least a day. Several of them I had been told, in one form or another, and had to learn anyway.

Fix a thing from the machine that can see it

The first week on the mini, pressing a row number in the dashboard was supposed to bring forward the laptop tab that held that session. It did not. I rewrote the fix every evening. Sixty-one commits in seven days. Every one of them was written in a session running on the mini, which cannot reach the laptop, so none of them could be tested end to end. I was fixing a window I could not see from the room I was standing in.

The fix that worked gave up on the laptop entirely. The cockpit does the whole jump inside the multiplexer on the mini: one machine, one process, no helper on the other side, no message passed across the network and waited on. The day it shipped, I ran five jumps from the laptop and none failed. The lesson is not about terminals. If you are going to fix something, stand where you can watch it break.

One copy, and know which machine you are on

On October 3 I typed a deploy command on the laptop instead of the mini. The laptop still had its own old copy of the site, weeks behind, and production rolled back to it. A stylesheet went missing, a profile page returned a 404, and a button I had rewritten went back to its old label. It took an hour to notice and ten minutes to fix.

The rule since then is simple and a little humbling. Anything that touches the live site runs on the mini, and when a session needs my hands for it, it hands me the command in a form that runs there and not here. Two copies of a thing is one copy too many, and the second one does not announce itself.

“Opened” has to say where

When a session finishes a page for review and opens it, the window appears on the mini’s screen. The mini has no screen. I asked three times one morning for a file to open before anyone figured out that it had, in a room nobody was in. A path pasted from the laptop is just as invisible in the other direction.

So files travel as attachments now, and reviews travel as one self-contained HTML file I can pull to the laptop with a single command. It is a small, true, slightly funny lesson: a machine with no monitor will happily open anything you ask, forever.

The fix is not live until the old process dies

Twice in one night I reported a bug as still broken after it had been fixed. The fixes were right. The dashboard I was looking at had been started before the fix existed, and the shell I was typing in dated from the day the machine was set up. Old code kept running under the new code’s name.

Now the dashboard re-executes itself when its own file changes. Every command on the mini is a link into the repository, not a copy of it. The laptop’s helper pulls and reloads on a message. I would have told you I knew all this. I knew it the way you know you should stretch.

A dropped connection is the normal case

I move between offices. The connection dies, and it dies in the middle of something, every time. The first few days the terminal tab I came back to would be typing a stream of numbers into whatever I had open, which is what a terminal does when the far side disappears before it can switch the mouse off.

The connect script now cleans up after a drop and waits for the mini to answer, then puts the tab back on the window it was showing. The mini’s side drops dead connections after ninety seconds instead of keeping them forever. At one point it had twenty-two ghost sessions from laptop tabs that had closed days earlier. The machine never noticed they had left.

The clipboard was never the keyboard

For three days I could not copy text out of a session on the mini and paste it on the laptop. Three different sessions diagnosed the problem. One blamed the keyboard. One told me to hold a key while dragging. One rewrote a configuration file. The copies were sitting on the mini’s own clipboard the whole time, because my terminal application ignores the signal that would have carried them across.

A twenty-line bridge now carries each copy over to the laptop. The status line says so when it works and says why when it does not. One hundred and eighty copies since, none lost. The diagnosis took longer than the fix by a factor of about fifty, which is the usual ratio.

The mini is where the local-only loops live

I run a handful of recurring processes that each used to need me to start them. One of them, the welcome note to new newsletter readers, had been stuck for weeks because it needs a connector that only exists on a machine of mine. It could not run in the cloud. It has now run every morning at 8:00 since September 23 as a scheduled job, and it drafts the notes into my email without sending a single one.

The gotcha was that the scheduler’s shell found an old copy of the Claude Code binary before the current one, and a Friday job failed silently until the script named the right binary by its full path. Every scheduled job on the machine now does.

Headless has edges

No monitor means no microphone, which means the dictation tool I use for most of my writing runs on the laptop and travels over the connection. No Excel on the mini means the family budget spreadsheet round-trips through the laptop for its one required save. No Apple ID means no shared clipboard from the phone. None of these are problems. Each one is a workaround I carry, and the list is worth writing down before you start so that you are not surprised by it at 10 p.m.

What runs while I sleep, and what does not

The scheduled jobs are the reason the mini exists, and they are also where I am most careful. The rule I use is borrowed from the one I wrote about in the brand guide: a loop goes last, after the folder, the voice, the look, and the gates, because those are what make it safe to run without me.

What runs alone: the welcome drafts, which draft and never send. The hours reconstruction, which writes a draft I sign on Friday. The folder sweep, which archives and never deletes. The health fetch, which reads. The publish job, which ships only what I have already signed off on, at a time I set. Every one of them writes to a known place, posts one line to a channel I read, and stops at a gate.

What never runs alone: anything with my name on it, and anything with someone else’s. I write every essay. No interview profile goes live until the person in it has read it. No deploy to the live site happens without a command typed by a person, on the right machine.

That line is the whole subject of the next essay, and I will leave it there.

What is still rough

• The laptop half of the file sharing is built and tested but not installed. Finder on the laptop still shows a stale copy of the projects folder, which is exactly the confusion the work was meant to end. It needs ten minutes and a password.
• The site’s working copy on the mini runs weeks ahead of what is committed. The October 3 rollback was one symptom. Until I commit after every launch, every deploy has to be typed on the mini.
• One of the six scheduled jobs failed its last run and told no one. I found it by listing the jobs for this guide.
• Both Macs still report the same identity to the browser extension that lets a session drive Chrome, so browser work flips between machines unless I remember to turn one off.
• The machine rebooted once, on October 2, for a reason I did not record. The boot script brought everything back. One unexplained reboot is fine. A second one gets a look.

What I am doing next

1. Install the laptop half of the file sharing and commit the scripts. After that, opening a terminal in any project folder on the laptop lands in that project’s session on the mini, and a session can put a finished file on my laptop screen itself.
2. Make the site safe to deploy from anywhere, by committing the working copy after every launch or pointing the scheduled publisher at the mini instead of the repository.
3. Move the next recurring process onto the mini. The content pipeline is the candidate. Same pattern as the welcome loop: a scheduled job, one line to the channel, a gate.
4. Write the essay. The guide is the method. The essay is the house humming at 3 a.m., and what it is like to wake up to work that happened while you slept.

If you want to build one sidebar

You need less than you think, and the order matters more than the parts.

• A small always-on Mac. Any Mac mini. Mine is an M6 with 32 gigabytes, which is more than the sessions use. The point is that it never leaves the house.
• The same username on both machines. Every path, memory file, and project folder then has the same address on the laptop and the host, and the setup files carry over without editing.
• A private network. I use Tailscale, which is free for one person and makes the host reachable from any office or phone without opening anything to the internet.
• A terminal multiplexer. tmux. Sessions survive the connection dropping, and you reattach from any device to the same window.
• Claude Code with Remote Control on. Each session started that way shows up in the Claude app on your phone. That part is built in; nothing to install.
• A boot script. One scheduled job at login that opens the multiplexer and one window per project. Then a power cut is a ten-minute pause, not a morning.

The order: network first, so you can reach the host from the laptop before anything else is on it. Then the multiplexer and the boot script, so the host comes back on its own. Then move the sessions. Then, and only then, the scheduled jobs, because by that point you know which machine the work is on and what happens when it restarts.

What I would skip: anything that syncs folders between two machines. One copy, on the host, and the laptop looks at it over the network. Every sync tool I considered ends in two copies and a question about which one is right.

The house at 3 a.m. Everyone asleep but one small machine, and the night running out of it like a river.

I keep coming back to the plan I wrote in August, because the mini was the last line of it, marked optional. Buy it only if the two-week trial proved out. The trial proved out, and the machine now holds every live session I have and six jobs that run without me. The next line on that plan is not more scripts. It is deciding which of the loops I trust to run without a gate, and that is a question about me, not the computer.

One essay, every Sunday morning, on making a life and a living while the machines learn to do both.

— Joe