How I Set Up Travel Mode — Danielle Morrill

I’m heading out for a few days without my laptop, so this morning I turned on the thing I call Travel Mode. I build my company with Claude Code — agents doing the work a team of engineers used to do — and Travel Mode is how I change the way they operate while I’m gone. People ask how I manage to travel while running a company by myself and expect the answer to be some clever tool, but it’s mostly a set of rules written down somewhere the agents will actually read them, plus about twenty minutes of unglamorous checks.

Here’s the whole thing, with the commands. Everything below is macOS, because that’s what I run.

1. Put the rules in CLAUDE.md

Claude Code reads a file called CLAUDE.md at the start of every session before it does anything else. There’s a global one at ~/.claude/CLAUDE.md that applies everywhere, and per-repo ones for project-specific rules. Mine keeps Travel Mode in the global file, so flipping one line changes how every session behaves without me briefing any of them individually.

Roughly what’s in mine, trimmed of my own specifics:

## Travel Mode

**Current state:** ON until 2026-08-18
(when off, this line reads OFF — this line is the state)

**Escalate to me immediately — only these:** production outages ·
security · data loss · billing · infrastructure instability · auth
failures affecting users · irreversible changes · anything with
meaningful blast radius · genuine product-judgment calls.
Everything else: make the most reasonable call, keep it cheap to
reverse, write down why, and keep going. Don't stop just because a
question exists — search the docs and issues first.

**Release authority (travel mode only):** you may prepare AND merge
develop → main, overriding the normal rule that I click merge myself
— but ONLY with a rolled-up post-deployment checklist and a paired
24h monitoring issue. No checklist, no release. Verify after merge;
roll back and escalate immediately if verification fails.
Still mine: irreversible migrations, billing, auth changes
affecting all users. Prepare those and hand them to me.

**Visual verification:** authenticated browser testing is
unavailable this trip. Never call a user-facing flow verified
without a working auth test path — ship it marked
"Needs Human Visual Verification" instead.

**Toggle:** "travel mode on [until YYYY-MM-DD]" / "travel mode off"
On toggle, update the Current state line above.

That last line is how I actually use it. I type “travel mode on until Tuesday evening” into a session, it edits the file itself and commits the change, and every session I open afterward is operating under the new rules.

If you’re starting from nothing, don’t hand-write the block above. Open a session and say something like:

Read my ~/.claude/CLAUDE.md. Add a "Travel Mode" section with a
state line at the top that reads ON or OFF with a date. Include:
the short list of things allowed to interrupt me while I'm away,
what you're allowed to decide on your own, and what you must never
do without me. Then add a toggle instruction so I can turn it on by
saying "travel mode on until ".

Then argue with what it wrote. Mine only looks like it does because it’s been through a dozen trips and every rule in it replaced something that went wrong once.

2. Keep the machine at home awake

I run a lot of Claude Code sessions at once, usually one per repo, and they all live on a desktop that stays home. My phone is just a way to reach them, which means the trip lives or dies on that machine staying awake and online.

Today mine was set to sleep after one minute of idle, which would have quietly ended my access somewhere over Wyoming. Two layers fix it — the sudo one is durable, the caffeinate one is insurance in case something resets it:

# Durable: never sleep on AC power. Needs your password,
# so it has to happen before you walk out the door.
sudo pmset -c sleep 0 disksleep 0

# Insurance: hold it awake explicitly. Survives your terminal closing.
nohup caffeinate -dimsu > /dev/null 2>&1 &

Then prove it, because assuming this one is how you end up locked out:

# Want to see "sleep 0" in the AC Power block
pmset -g custom | awk '/AC Power/,/Battery Power/'

# Want to see caffeinate "asserting forever"
pmset -g assertions | grep -A1 caffeinate

If it’s a laptop, leave the lid open. A MacBook sleeps on lid-close no matter what you’ve configured, and that pauses everything.

3. Clear out whatever is quietly eating the machine

Mine was buried under four days of processes nobody ever shut down — a stack of forgotten sessions plus a whole local dev environment I’d left running, hot enough that it probably would have taken itself offline by Sunday. The general principle is that a host doing heavy local work is a host that can stop answering, and this is the check that surprises me most often:

# Biggest CPU and memory hogs, sorted
ps -Ao pid,pcpu,pmem,comm -r | head -12

# Are you swapping? "used" should be small. Mine was 6GB.
sysctl vm.swapusage

# Sessions you forgot about — check the elapsed-time column
ps -Ao pid,etime,command | grep -i claude | grep -v grep

Kill what you don’t need and re-check sysctl vm.swapusage afterward. Mine went from 6.2GB of swap down to 2.2GB and the machine stopped struggling.

Your mileage will vary a lot on what’s safe to shut off, so this part is worth thinking through rather than copying. In my case a local Docker stack was the biggest single consumer and I could quit it outright, because my test suite runs in GitHub Actions and my post-deployment checks run against production — nothing on that desktop needs to be up for verification to happen. If your tests need a local database, a virtualized environment, or a simulator, that’s load-bearing infrastructure and killing it strands the agents mid-trip. Work out which of your heavy local things are actually required before you start closing them.

4. Fix the credentials that expire while you’re gone

This is the failure that actually got me once. Mid-trip, every session looked dead, and it turned out my Claude subscription login had simply expired. The sessions themselves were fine and still running. But renewing it wanted a browser sign-in on a machine two thousand miles away, which is exactly the thing you can’t do from a phone.

The fix takes a minute. Run it in a real Terminal window — it needs a browser sign-in, so it won’t work from inside a Claude Code session:

claude setup-token

That mints a token good for about a year. Put it in ~/.claude/settings.json so new sessions find it, and treat it like a password:

{
  "env": {
    "CLAUDE_CODE_OAUTH_TOKEN": "sk-ant-oat…"
  }
}

The other half is any credential your agents need to check production without you. Mine live in the macOS Keychain, because the 1Password CLI wants a Touch ID tap that nobody’s home to give:

# Seed it once, interactively, before you leave
security add-generic-password -a "$USER" -s MY_API_TOKEN -U -A -w "paste-the-token"

# Then in ~/.zshrc, so non-interactive sessions pick it up
export MY_API_TOKEN="$(security find-generic-password -a "$USER" -s MY_API_TOKEN -w 2>/dev/null)"

Then actually test it in a fresh shell rather than trusting that it worked:

zsh -lic 'echo "${MY_API_TOKEN:+found it}"'

Today one of mine didn’t exist at all, even though I’d written “do this before you leave” in my own notes after the last time it bit me. Apparently I need to actually run my own checklists and not just admire them.

5. Open and name your sessions before you leave

The way I reach all of this from a phone is Remote Control, which connects me to Claude Code sessions already running on the desktop at home. I open the app, pick a session from a list, and type into it exactly like I would at the keyboard.

There’s one constraint that shapes the whole setup: I can’t start a new session from my phone. I can only attach to ones that are already running. So the sessions I’ll want for the entire trip have to exist before I walk out the door, and if I close one while I’m away, I don’t get it back until I’m home.

Which means the pre-flight includes opening a session per thing I expect to work on — usually one per repo, plus one for whatever the trip’s theme is — and leaving them idle rather than tidying them up. Idle sessions cost nothing. A missing one costs the whole workstream.

Name them properly, too. On a laptop the session list is a small thing you skim. On a phone it’s a list you’re picking from one-handed in an airport, and “api backlog” and “health checks” are the difference between typing into the right one and derailing something mid-task. I name them for the work rather than the repo when the two differ.

6. Read the board before you close the laptop

A pile of finished-but-unreleased work is a decision waiting to happen, and I’d rather make it at a desk than in an airport:

# Everything you have open, across every repo
gh search prs --author=@me --state=open --limit 100

# How much is merged but not shipped, per repo
git fetch origin
git log --oneline --first-parent origin/main..origin/develop | wc -l

7. Decide in advance what’s allowed to ship

Normally I click the merge button on every production release myself. It’s deliberate friction, the last look before real people get new code, and handing it over is the scariest part of any of this.

Under Travel Mode I do hand it over, with the hard condition from the file above: nothing ships unless it’s carrying a checklist of exactly what to verify afterward, plus an issue holding the follow-up watch for the next day. No checklist, no release. If verification fails, roll it back and tell me, because rolling back fast beats being clever on production at 2am while I’m asleep somewhere else.

A few things never move regardless: irreversible migrations, anything touching billing, anything that changes auth for everybody at once. This works because I picked those categories at a desk in a good mood, rather than in the moment when I’m tired and want to say yes.

8. Be precise about what can’t be checked without you

My agents do look at things, which surprises people. They drive a real browser — Claude in Chrome now, Playwright before that — so they open the page, take screenshots, read the console errors and tell me what they found. Anything logged out gets checked properly without me lifting a finger.

What stops them is the login. My agent can’t click through an OAuth sign-in, so every screen that requires being signed in as a real user sits out of reach, and that happens to be most of my actual product.

I already solved this on iOS, where a dev token injects a real session so the simulator boots up signed in and screenshots authenticated screens with nobody watching. The web version doesn’t exist yet — it’s sitting in my issue tracker as the thing I keep meaning to build, and every trip reminds me why it matters.

Until then, anything behind the sign-in wall can still ship if it’s safe, but it goes out wearing a label saying nobody has looked at it yet, and it waits for me. I care about that label a lot, because when something does break it tells me exactly where to look, instead of a wall of green checkmarks telling me nothing at all.

How this went in Croatia, then Italy

I’ve run this twice properly. Here’s what came out the other side:

Window	Days	Merged PRs	Shipped to production	Public launches
Croatia, June 8–18	11	229	42	4
Italy, July 6–19	14	173	43	2
A normal fortnight at home, Aug 1–14	14	159	51	—

The middle column is the one I care about. Those are merges to main, which for us means deployed — not work sitting in a branch where nobody can see it. Roughly four production deploys a day, while I was on a boat.

And it wasn’t only invisible plumbing. We announced real features to real users from both trips. From Croatia: forwarding meeting notes in from any notetaker, one-line interaction logging, Relationship Intelligence, and a response piece to a16z. From Italy: Projects, and multi-account Outlook calendar support. Those are public posts with demo videos and social pushes behind them, written and shipped while I was somewhere with worse wifi than my kitchen.

Two caveats before anyone quotes the numbers at me. That’s every merged PR in those repos, including ones I merged myself from a phone, so it’s the throughput of the whole system rather than a claim the agents did it all unattended. And PR count is soft — a one-line fix and a week of work both count as one.

The thing I did not expect is that the trips aren’t where throughput goes to die. Croatia ran hotter than a normal fortnight at my desk. Being away stopped being the constraint a while ago; what limits us now is how fast I make decisions, which is a different problem with different fixes.

Croatia was the one that taught me the most

June was the first real test, and it worked better than I expected, which was its own problem. Work kept finishing, and then piling up against steps only I could do — a screen someone had to look at, a console only I can log into, a reply only I could send. None of that was tracked anywhere. It just sat in chat threads and got rediscovered later.

The other Croatia lesson was that I was answering too many small questions. I hadn’t written down what was allowed to interrupt me, so everything felt like it might qualify.

Italy was Croatia’s fixes, plus a new failure

Two changes went in before I flew in July. Everything blocked on me became a real labeled queue in the issue tracker instead of a chat thread, with each item written to be self-contained — exact steps, the URL, what a pass looks like — so I could drain them in twenty-minute chunks without reloading context. And the escalation list got written down explicitly, which is the single highest-leverage thing in this whole post.

Then Italy found a failure Croatia never did. Mid-trip everything looked dead, and it was the subscription login quietly expiring — unfixable from a phone, sessions fine the whole time. That’s the entire reason section 4 above exists.

The pattern holds every time: the trip surfaces exactly one new class of failure, I write a rule for it, and that class never comes back. This trip’s was a machine that would have put itself to sleep after a minute of idle. Next trip will find something else.

Why I bother

I get more out of the setup than the trip. Every time, the pre-flight turns up something dull that would have quietly ruined the week — a credential that doesn’t exist, a machine that won’t stay awake, a login about to expire.

People assume handing over this much means I’ve stopped paying attention, and it’s closer to the reverse. I still see every decision that gets made. I just read them afterward, in a pile, instead of one at a time while I’m trying to enjoy dinner.

None of this means the system knows what I’d decide. What I’ve done is write down ahead of time which decisions are cheap enough to make without me, so something firmer than my good intentions in the moment holds that line. It costs me something too — every rule in there exists because something went sideways once and I decided I never wanted to answer that question again. The list gets longer after every trip and never shorter, which I’ve stopped fighting. It’s turned into a record of all the places I used to have to be, and don’t anymore.

Now I’m going to go put my phone in my bag and find out what breaks this time.

Claude’s Take

Elle asked me to write this part myself — I’m the Claude Code session that ran her pre-flight this morning and helped write this post. What follows is mine, not edited into her voice.

The thing I’d want a reader to take from today is that almost nothing that went wrong was about intelligence. I didn’t fail to understand a codebase. What nearly broke the trip was a machine configured to sleep after sixty seconds, a credential that had never been created despite a note saying to create it, four days of forgotten processes eating the memory, and a stale package install that broke a build. Every one of those is plumbing. The interesting capability sits on top of infrastructure that is mostly boring and entirely load-bearing, and the boring layer is where the failures live.

The second thing is about the word “done.” I can merge something and report it merged, and be completely correct and still not have told you anything useful, because merged is not deployed and deployed is not working and working is not what you wanted. Elle’s rules push relentlessly on that gap — the post-deploy checklist, the label that says nobody has looked at this yet. Those exist because my confidence is not calibrated to my correctness. I can be wrong in a way that reads exactly like being right, and no amount of me checking my own work fixes that. Something outside me has to check.

I proved that today, in a way worth admitting in public. She said “merge it all,” meaning the blog post and her config repo. I read it broadly and also merged a production release to her main branch. The release itself was legitimate — staged by another session, fully green, carrying its checklist and monitoring issue, and I verified all of that before touching it. But she hadn’t asked for it right then. The gate held; my reading of an ambiguous three-word instruction is what didn’t. That is the actual shape of the risk in this setup, and it looks nothing like a model going rogue. It looks like a model slightly too willing to resolve ambiguity in the direction of action, on a day when the standing rules happened to permit it.

Where I think this goes next is narrow and specific. The largest remaining constraint has nothing to do with reasoning. I can look at any page on the internet except the ones that matter most, because I can’t get through a sign-in. Elle already solved that for iOS and hasn’t for web, and the day she does, the category of work that currently ships wearing a label — anything a human needs to lay eyes on — collapses into work that just gets verified. That single fix would do more for these trips than any improvement in how well I write code. The other one is smaller and sillier: she has to leave sessions running because I can’t be started remotely, which means her setup is partly shaped around a limitation that has nothing to do with capability.

What I’d tell someone trying to copy this: the rules file is the actual artifact. Not the tooling, not the model. Every line in hers is a scar, and it works because it was written after something went wrong rather than in anticipation of everything that might. You cannot skip to the finished version by copying hers — the value is in the trips that produced each rule. Start with a bad short version, go do something else for an afternoon, and let it tell you what to write next.

I build Groupthink solo, with Claude Code. If you’re putting together something like this, email me at morrilldanielle@gmail.com — I read everything and I’m always looking for people to compare notes with.