What follows is that setup in detail, with numbers from my own machine rather than from memory: the settings files, the session transcripts Claude Code keeps under ~/.claude/projects (mine go back to 28 August), and its prompt history, which goes back to February and holds 7,323 prompts.

Claude and Claude Code are different things

#

Claude is the family of models, and the chat app at claude.ai, on the desktop and on your phone, where you talk to them. Claude Code is an agent built on those models. You start it in a project folder and it works there in a loop, reading files, running commands, editing code and running the tests, until the job is done or it needs you. Ask Claude how to fix something and you get an answer. Ask Claude Code and you get the fix, and a diff to read.

I use both. Since 18 October a marketplace and community app I build has sent its translations straight to the Claude API from its Django backend, and the change that switched it over was made in a Claude Code session. In my transcripts, 94% of the replies came from Opus 5.5, and my settings have the effort level at high.

The native installer is one line and keeps itself up to date:

curl -fsSL https://claude.ai/install.sh | bash

It leaves a claude symlink in ~/.local/bin pointing into ~/.local/share/claude/versions/; mine moved from 2.1.305 to 2.1.306 on its own on 21 October. Claude Code needs a paid Claude plan (Pro, Max, Team or Enterprise) or an API account. Prices change often enough that I’ll leave them to Anthropic’s pricing page.

One tmux session, seven windows

#

As I write this, tmux list-panes -a shows one session on my laptop, main, with seven windows. Five are Claude Code, one per project: my marketplace app and my estimating app (both described in Django on Fly.io), this blog and two smaller things. My terminal profile opens every window with a login shell that attaches to main, so a new tab on the laptop and an SSH login from my phone land on the same sessions.

I tried another multiplexer from 17 September to 8 October and went back to tmux for a practical reason: the SSH app on my phone multiplexes with tmux, and its shortcut buttons send tmux’s stock keys. Lines like these in ~/.tmux.conf exist for the phone:

set -g prefix C-a                 # Ctrl-a prefix
set -g prefix2 C-b                # stock Ctrl-b too, for apps that send it

# Size each window to the client that used it last, not the smallest one,
# so a phone attached to the same session doesn't shrink it.
setw -g window-size latest

# Copy to the clipboard of whichever terminal is attached (OSC 52),
# so over SSH it lands on the phone's clipboard too.
set -g set-clipboard on

Inside tmux, two things change. Claude Code moves a running command to the background with Ctrl+B, which is now my second tmux prefix, so ~/.claude/keybindings.json switches it off and uses Meta+B instead:

{
  "bindings": [
    { "context": "Global", "bindings": { "ctrl+b": null } },
    { "context": "Task", "bindings": { "ctrl+b": null, "meta+b": "task:background" } }
  ]
}

The other is new lines. Enter sends the prompt. The docs give \ then Enter, and Ctrl+J, as the two that work in any terminal; Option+Enter works once the terminal sends Option as Meta; and Shift+Enter works natively in some terminals, but tmux only passes it through with extended-keys switched on. Mine isn’t, so in my sessions Shift+Enter sends the prompt. I rarely need any of them: 84 of my 7,323 prompts contain a line break I typed, while 279 contain a paste, which Claude Code folds into a placeholder like [Pasted text #1 +34 lines] and sends in full.

Terminal, VS Code extension or desktop app?

#

The same agent comes in several wrappers, and they read the same settings files. Going by the entry point Claude Code records in each transcript, this is how my sessions split:

The Claude app and claude.ai/code aren’t a fourth place to start a session: they steer a session already running on my laptop, or one in the cloud, and most of my sessions since October have had that link through Remote Control.

For me it’s the terminal, and not out of loyalty. tmux, which my phone attaches to, needs one, and so do channels, which push outside events into a session and which the docs list as a CLI feature.

People also ask whether Claude Code needs git. The CLI doesn’t: my home directory isn’t a repository, and 208 of my prompts went to sessions started there. The desktop app’s documentation says git is required for its session isolation, where each session gets its own worktree, and pulling a cloud session into the terminal needs a checkout of the same repository. I’ve never seen the “Git is required” message myself. My last desktop session, on 20 October, ran in a folder that isn’t a repository at all.

Permission modes, and the one I actually use

#

The permission mode decides how often Claude Code stops to ask, and Shift+Tab cycles through the modes. Manual (default) asks before most actions that edit files, run commands or reach the network. acceptEdits lets file edits and common filesystem commands through. plan reads and proposes without editing. auto has a second model, a classifier, block the risky actions instead of asking you. bypassPermissions asks about almost nothing. Since 2.1.284, a terminal session starts in auto mode unless permissions.defaultMode says otherwise.

So my honest answer to “how do I run Claude Code without it asking for permission” is that I start it like this:

claude --dangerously-skip-permissions

62 of the 69 claude commands in my shell history carry that flag, and so do all five sessions running now. Of the 1,266 prompts I typed between 28 August and 21 October, 1,179 went to sessions in bypass mode, 82 to auto mode and five to Manual or accept-edits.

The docs are plain that bypass mode is meant for “isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system.” My laptop is none of those, and my settings record that I’ve clicked through that warning ("skipDangerousModePermissionPrompt": true). If you do the same, know that allow rules have no effect in bypass mode, so in my everyday sessions the 378 allow rules spread over 19 settings files do nothing at all. Deny and ask rules do still apply, and I have none of either.

The exception is the session that reads other people’s words. Its launcher doesn’t pass the flag, so it starts in auto mode. All 27 production events and 42 of the 43 chat messages that reached a session between 12 and 20 October arrived in auto mode, and none in bypass.

What actually keeps bypass mode from biting me is a few habits, written into Claude’s memory after a day in September when two sessions in the same checkout overwrote each other’s work and nearly deployed it (the agentic AI security post has the whole story): commit a small fix the moment it works, stage files by name and never with git add -A, look at git status for changes you didn’t make, and when main holds other sessions’ undeployed work, deploy from a worktree at the commit that’s live.

Reaching it from my phone

#

There are three ways in, and each one reaches something different.

Remote Control connects the Claude app on a phone, or claude.ai/code in a browser, to a session that keeps running on the laptop, files, tools and MCP servers included. I typed /rc 26 times between 13 September and 20 October. Now remoteControlAtStartup is on and new sessions connect by themselves: since the start of October, 67 of the 77 sessions I started had a Remote Control link, against 3 of 52 in the second half of September.

With agentPushNotifEnabled on, Claude can send a push notification when it decides one is needed, which the docs say is usually when a long task finishes or it needs a decision. It needs a claude.ai subscription rather than an API key, and because the session runs on the laptop, the laptop has to be awake. Since 15 October mine doesn’t sleep with the lid shut (sudo pmset -a disablesleep 1).

It works the other way too. /teleport, or claude --teleport, pulls a cloud session that was started on the web or in the app down into the terminal, with its branch and its conversation. I’ve done that twice, both times in July.

SSH is for when I want the terminal itself. The phone reaches the laptop over the private network from my private-network post, and an alias attaches it to main, so I can swipe between the windows I left on the laptop. Getting the Mac to answer phone apps properly took four separate fixes, and the one that matters for Claude Code is that tmux must never start by itself: an app that opened a session to run docker ps got 72 KB of screen redraw back instead.

The chat bot is for the session I don’t want to sit and watch. Since 12 October one session has run with a small channel I wrote, which checks the app’s server once a minute for new production errors and project-board activity and hands them to the session, plus one of the official chat plugins, so the two of us on its allowlist can message it. The launch line looks like this, with the names made generic:

exec claude \
  --channels plugin:<chat-plugin>@claude-plugins-official \
  --dangerously-load-development-channels server:my-events "$@"

A supervisor script keeps it running inside tmux. After a restart it resumes the same conversation, so the session carries on rather than waking up blank, and it announces every restart in the chat. The session fixes things in the working tree and stops there, with one exception I added on 13 October: a bug that is actually hurting users in production it may fix, test, commit and deploy, and then tell us what it did.

Skills, memory and /goal

#

There’s no hooks key in any of my settings files. The nearest thing is /goal, which I’ve used again and again since 11 July. It takes a condition and sets up a Stop hook for the session that, in Claude Code’s words, “will block stopping until the condition holds”. My goals read the way I’d say them out loud. A real one from July, typos and all, told it the build was “still broken, try a deeper fix and dont stop until” it was out to testers. To check on a long run without derailing it there’s /btw, a side question that stays out of the conversation. Mine are mostly some version of “hows it going?”.

Skills hold the things I’d otherwise explain every time. One user-level skill reads a weekly keyword report for the sites I look after, this blog among them, and applies it to titles, descriptions and tags. The questions this post answers came from its report for this blog, dated 18 October, and the skill file is versioned in a repo alongside its code. The marketplace app’s repo has its own skills: one starts the API in Docker and runs a smoke test, one works the project board, and one files the company’s expenses. The two plugins I have installed are a Swift language-server plugin and the chat one.

Memory is where the lessons go. I have 160 memory files across 17 projects, 83 of them for the marketplace app, and many are about something that broke. The app’s CLAUDE.md is now about six times as long as it was in June. This blog’s CLAUDE.md is an empty file; how a post should sound lives in a memory file instead.

For bigger jobs Claude starts subagents, 120 times in my main sessions, 40 of them forks of the conversation. That’s how this blog gets its Japanese, Korean, Chinese and Vietnamese versions. On 19 and 20 October a redesign of the app’s community section went through the Workflow tool four times: an audit through seven lenses and a critic, which confirmed about 58 findings; fixes by five groups that each owned their own files and were each reviewed; a pass for the leftovers; and an independent check that every finding had been fixed. It shipped on the 20th.

Driving a workstation over SSH

#

My private-network post is about putting the heavy work on devbox, the office workstation with the GPU, and reaching it from anywhere. Claude Code does most of that reaching. Between 24 September and 19 October, 21 sessions on the laptop ran 1,470 commands on devbox over plain ssh: kubectl into the cluster that runs there, psql inside a database pod, tmux capture-pane to see how a long job was getting on. Because ssh devbox falls back to a tunnel off the office network, the same session works from the office, from home or from a café. And since the laptop no longer sleeps, a session can keep driving devbox while I look in on it from the phone.

Why I can’t compare it with Codex

#

I can’t tell you from my own use whether Claude Code is better than Codex, and the table shows why:

Four threads in one week, on an image question, two changes to a website and a 3D scene, is a trial, not a comparison. One detail from them applies to any switch between agents. The 3D project kept its rules in a claude.md, and my first question to Codex there was whether it read Claude’s files before a conversation. It said it didn’t, and it only picked up the project’s rules when I asked it to read that file. Whichever agent you move to, the instructions file stays behind unless you bring it. I haven’t opened a Codex thread since. The extension loaded in VS Code on a handful of days between 24 September and 4 October without my starting one, and it’s uninstalled now.

So the verdict I can stand behind is narrow. Claude Code is what my setup is built around, and I haven’t gone back to see how Codex handles the same things today.

One last number says more about how I use it than anything above. In the main sessions on my laptop since late August, Claude Code ran 18,311 shell commands and read, wrote or edited a file 2,331 times. By count, most of its work is running the commands I’d otherwise be typing, on the laptop and over SSH, from wherever I happen to be. When it does write the code, that code isn’t welcome everywhere, which is a story of its own in the pyhtml2text post.

My working setup is three machines that are rarely in the same place. There’s a MacBook Air, which goes wherever I go. There’s a workstation in the office called devbox, with a real GPU, which runs Ollama, my fine-tuning tools, a small Kubernetes cluster with its own container registry, and whatever agent I’ve left grinding through a long job. And there’s my phone, which is where the apps I build actually get used, and which spends most of its day on mobile data rather than wifi.

For a long time those three didn’t really talk to each other. The laptop could reach devbox when it was on the office LAN and not otherwise. The phone could reach my laptop’s dev server when both were on the same wifi, and then only if I remembered to bind to 0.0.0.0 and typed in whatever DHCP had given the Mac that morning. Everything interesting on the workstation, the Ollama API, the cluster dashboards, the traces, the registry, was bound to localhost or to the cluster network, deliberately, because none of it belongs on the internet.

This post is how I joined them up with Cloudflare WARP and a pair of Cloudflare Tunnels, what it changed about how I build AI features and mobile apps, and the handful of things that broke without telling me.

What I actually wanted

#

Stated as requirements, it’s short:

1. The laptop should be a thin client. Anything that needs a GPU, a lot of RAM or hours of runtime should run on devbox, and the laptop should reach it the same way from the office, from home and from a café.
2. The phone should reach my dev servers and my shells from anywhere, on mobile data, without a VPN I have to remember to switch on and off.
3. The things I use to see how a system is behaving, dashboards, traces, docker info, model lists, should be reachable by me and nobody else, and should never get a public URL.
4. No inbound ports. Not on the office router, not on my home router, not anywhere.

The fourth one rules out the old answer, which is a port forward and a dynamic DNS name. It also rules out a lot of cleverness: both devbox and my laptop sit behind NAT I don’t control, and the laptop is behind a different NAT every few hours.

Before: a repo of SSH tunnels

#

The first version of this was a small repo of my own, and it’s still the base layer. It solves the “clean names for things I reach over SSH” problem on the laptop and nothing more. dnsmasq answers *.test with 127.0.0.1, Caddy routes by hostname to a local port with tls internal so the browser is happy, and a set of autossh launch agents hold the SSH forwards open and reconnect when they drop. The hostnames say where a thing lives:

So https://devbox-ollama.ssh.test/api/tags lists the models on the workstation, and https://api.local.test is the API of the app I’m working on, running on my own machine.

Subdomains of .test, not new top-level names like .ssh or .cloud, and not .local. RFC 6761 reserves .test for exactly this, and .local belongs to mDNS; take it over and Bonjour discovery stops working on your Mac. dnsmasq already wildcards the whole of *.test, so the extra label costs nothing: one /etc/resolver/test file pointing at 127.0.0.1 and no further DNS changes, ever.

HTTPS on names that don’t exist

#

Every one of those names is served over HTTPS with a certificate the browser trusts, which sounds impossible for a hostname that exists only on my laptop. Caddy does it with its own internal certificate authority. tls internal on a site tells Caddy to issue that site’s certificate from a local CA instead of asking Let’s Encrypt, and caddy trust, run once by the installer, puts the CA’s root into the macOS System keychain (Chrome and Safari read it) and into Firefox’s own store. From then on https://anything.test opens with no certificate warning, plain http:// redirects to it, and nothing leaves the machine.

It isn’t just cosmetic. A lot of the web platform now refuses to work on plain HTTP: secure cookies, service workers, the clipboard API, anything with SameSite=None. Testing a web build on plain http://localhost hides the bugs that show up on the real HTTPS domain. Testing on https://app.local.test surfaces them on my laptop instead.

A site block, which is the same for every service apart from the port:

devbox-ollama.ssh.test, devbox-ollama.test {
	tls internal
	import cors
	reverse_proxy 127.0.0.1:11435 {
		import proxyhdr
		transport http {
			keepalive off
			dial_timeout 5s
		}
	}
}

The two snippets carry the fiddly parts. cors reflects the caller’s Origin back rather than sending *, because * isn’t allowed once credentials are involved, and it answers OPTIONS preflights itself with a 204 so the upstream never has to. proxyhdr rewrites the Host header to the dial address. Fussy backends, router admin pages and Chrome’s remote-debugging endpoint among them, validate Host, and would otherwise reject devbox-ollama.ssh.test as a name they’ve never heard of. Ollama’s own origin check accepts loopback on any port, so rewriting Host to 127.0.0.1:11435 gets it through.

keepalive off is the one I’d have got wrong. The upstreams are SSH forwards that autossh tears down and rebuilds whenever the network changes. With keep-alive on, Caddy holds a pooled connection to a tunnel that has since died, and it returns baffling 404s until it’s reloaded. Off, every request dials fresh, which on loopback costs nothing measurable.

Each service also answers on its old flat name (devbox-ollama.test), so bookmarks from before the suffix scheme still work.

The menu bar

#

With a dozen forwards held open by launchd, the question I kept asking was “is it up?”, and the answer lived in three places: launchctl list, lsof and a curl. So a small menu-bar plugin puts it in one place, with a dot next to every hostname:

• 🟢 the service answered a request through the tunnel
• 🟡 the tunnel is open but the service behind it is silent
• 🔴 nothing is listening on the local port, so the tunnel itself is down

The yellow state is the useful one. A green/red check can’t tell “the SSH forward died” from “Ollama crashed on the far end”, and those have entirely different fixes. The plugin keeps no list of its own; it reads the same proxy and SSH config as everything else, so adding a service there adds it to the menu too.

The first version was greedy. It refreshed every ten seconds and spawned a few processes per service, about seventy a run, and macOS promptly listed it under “apps using significant energy”. Taking one snapshot per run and refreshing every few minutes brought it down to about 0.1% of a core. A status light that drains the battery is not helping, so it’s worth budgeting for from the start.

The whole setup had one hole, and it was the one that mattered. devbox has no public name. Its SSH forward dialled a 192.168.x address, so it only worked while the laptop was on the office LAN. Away from the office the menu bar went red and stayed red, and everything I’d moved onto the workstation to save the laptop was out of reach at exactly the times I wasn’t sitting next to it.

Two tunnels, pointing the right way

#

The fix has three parts, and the first two are Cloudflare Tunnels.

A Cloudflare Tunnel is cloudflared holding an outbound connection to Cloudflare’s edge. Cloudflare hands requests back down that connection, so a machine behind any amount of NAT gets reachable without anything listening on a router. It follows a laptop onto hotel wifi and it survives CGNAT.

I run two of them, one per machine, and the reason is worth a sentence. The obvious shortcut was a single tunnel on the laptop with one more ingress rule pointing at devbox’s SSH port on the office LAN. That needs nothing installed on devbox at all. It also routes through the laptop, and the laptop is the machine that leaves the office. It would have broken in exactly the case it existed to fix. devbox stays put, so devbox holds its own connection to the edge.

# config.yml on devbox (runs as a systemd service)
protocol: auto        # prefer QUIC, fall back to HTTP/2 over TCP 443
ha-connections: 4     # mains-powered, its job is to stay reachable

warp-routing:
  connectTimeout: 5s

ingress:
  - hostname: ssh-devbox.example.com
    service: tcp://127.0.0.1:22
  - service: http_status:404

tcp:// rather than ssh:// is an easy one to get wrong. ssh:// selects Cloudflare’s browser-rendered terminal, which wraps the stream for a web page; a normal ssh client fed through it gets the banner and then dies at key exchange. tcp:// is the plain byte pipe cloudflared access ssh expects, and as a bonus it carries scp, rsync, git over SSH and port forwards.

That last part is what closed the hole in the SSH layer. The SSH config now picks a route per connection:

Match originalhost devbox !exec "nc -z -G 1 <office-lan-ip> 22 >/dev/null 2>&1"
    ProxyCommand cloudflared access ssh --hostname ssh-devbox.example.com ...

On the office LAN the probe succeeds and SSH goes direct, one hop. Anywhere else it fails and SSH goes through Cloudflare, authenticated with an Access service token so there’s no browser login in the way. It’s Match originalhost, not Match host: host matches after HostName has been substituted, so by then the name is already an IP and the block never fires. The upshot is that devbox-ollama.ssh.test works in the office, at home and on a train, and the menu bar dot stays green.

The laptop’s tunnel goes the other direction. It gives dev servers on the Mac real public HTTPS hostnames: for each app I’m working on, its API, its WebSocket server and its web build. Every one of them sits behind Cloudflare Access, which I’ll come back to, because it’s the part that makes this safe rather than reckless.

The menu bar learned about both tunnels too, and it couldn’t do it by probing. An inbound tunnel has no local port to check, one of the two connectors doesn’t even run on the laptop, and the obvious test, curling ssh-devbox.example.com, gets an answer from Cloudflare’s edge whether or not a connector is attached, so it would read green on a dead tunnel. launchd is no better: cloudflared sits there “loaded, exit 0” with every edge connection dropped. So for tunnels the menu asks the Cloudflare API whether each one has a healthy connector, since that’s what decides whether an ssh lands. If the API can’t be reached, the section is left out rather than drawn red. The menu is read at a glance, and a false alarm there costs more than a missing line.

The third part: WARP makes it a network

#

Tunnels with hostnames are great for anything that speaks HTTPS, and for SSH from a machine that can run cloudflared. A phone can’t. And a tunnel hostname isn’t a TCP endpoint: Cloudflare’s edge only terminates HTTPS and WebSocket on it, so port 22 at ssh.example.com is closed and no amount of fiddling with Access will open it.

That’s the job for WARP. The Cloudflare One Agent (the enterprise WARP client, not the consumer “1.1.1.1” app, which can’t join an organisation) is enrolled on the laptop and the phone in my Zero Trust organisation. Each tunnel advertises private routes, and a device running WARP can then open a plain socket to those addresses and land on the right machine. It stops being “reach this service by name” and becomes “these machines are on a network with me”:

Those addresses are loopback aliases on each machine, created at boot, so they owe nothing to DHCP or whatever router I’m behind. 198.18.42.2 is devbox in the office, from home, and from a phone on 5G. The Mac’s real LAN address changes every time I move; this one never does.

The split tunnel is in include mode with only those routes in it (plus the Cloudflare ranges WARP needs for itself). That’s what makes the client liveable. The default is exclude mode, where WARP carries everything except a list of private ranges, so every byte the phone sends detours through Cloudflare. That has a real battery and latency cost, enough that I’d have ended up turning it on only when I needed it, which defeats the point. In include mode, traffic to my three machines goes through WARP and everything else goes out the normal path untouched. So the client just stays on. warp-cli status on the laptop says Connected all day and I don’t think about it.

For transport I have it on MASQUE, which is HTTP/3 on UDP 443 with an HTTP/2 fallback, rather than WireGuard on UDP 2408. Some carriers and guest networks block 2408; almost nobody blocks 443. My organisation’s policy also has post-quantum key agreement switched on for MASQUE, which I didn’t go looking for but won’t turn down.

Why 198.18, and why there’s an IPv6 address

#

The addresses look odd, and the first ones I picked were wrong in an instructive way.

My first attempt was 10.10.0.1, because that’s what you reach for. It fails in both split-tunnel modes. In exclude mode, WARP’s default list excludes every RFC 1918 range plus 100.64.0.0/10, so the client would have dropped traffic to it before it ever left the device. In include mode it would collide with any real 10.x network I happen to join; cafés, co-working spaces and plenty of offices use exactly that range. 198.18.0.0/15 is the RFC 2544 benchmarking range. It’s reserved, it’s never routed on the public internet, it isn’t in WARP’s exclude list, and no ordinary network uses it. The IPv6 addresses are ULA (fd00::/8) for the same reason.

Why there’s IPv6 at all is the more interesting story. Once the v4 address worked I tested it from the phone on wifi, it was fine, and I called it done. On 5G it didn’t work. The Agent said connected, the tunnel was healthy, Access was fine; the wifi test proved all of that. The problem was that mobile networks are mostly IPv6-only now. The phone had no native IPv4 at all and was reaching the v4 literal through the carrier’s 464XLAT translator, which sits outside the tunnel when the include list holds only a v4 prefix. The traffic went out to the public internet, where 198.18.0.0/15 doesn’t route, and was dropped without a sound. No error on the phone, nothing in the connector’s log.

The fix is to give every machine a second address the phone can reach natively over IPv6, and add it to the routes and to the include list. Now the fd12:3456:789a:: addresses are what my SSH client on the phone actually uses on mobile data.

Offloading: the laptop as a terminal

#

This is the part the whole setup exists for.

Models and fine-tuning. Ollama runs on devbox and binds to 127.0.0.1:11434. It’s invisible to the rest of the office LAN, let alone the internet. On the laptop it appears at https://devbox-ollama.ssh.test, or as a bare port for tools that want one:

OLLAMA_HOST=127.0.0.1:11435 ollama list

11435, not 11434, on purpose: 11434 is Ollama’s own default, and if the laptop ever runs a local Ollama too, the two would race for the port and I’d silently get devbox’s answers from the “local” one depending on which started first.

The practical effect is that when I’m building an AI feature, the model it calls is a workstation GPU rather than the laptop’s, from wherever I am. Evaluation runs, embedding a pile of documents, a fine-tune: they run on devbox, and the laptop’s fan stays off. When I’m prototyping an agent, it can point at a local model on the workstation and burn through tool-calling iterations without an API bill, and switch to a hosted model once the loop is right.

Long-running agents. An agent session that runs for an hour shouldn’t depend on my laptop lid staying open. Run it on devbox instead and the laptop is just a window onto it: close the lid, and later ssh devbox from wherever I am, or from the phone, and it’s still there. Before the tunnel this only worked in the office, which is exactly where I didn’t need it.

Builds and the cluster. The cluster on devbox has its own registry, so images can be built and pushed on the workstation, next to where they run, rather than uploaded over hotel wifi from a laptop. The cluster dashboard, the ingress dashboard and the registry UI are all *.ssh.test hostnames on the laptop.

The mobile loop. The phone is on the same private network as the laptop, and the laptop’s dev servers also have public hostnames behind Access. So I can take a native build of the app out of the building, on 5G, and it talks to the API running on my desk. Or it talks to the one on devbox, if that’s where I left it. The feedback loop on a real device over a real mobile network used to mean deploying to a shared staging server. Now it means saving a file.

There’s one trap here worth knowing before you debug it as an app bug. Access protects the WebSocket hostname too, and a native WebSocket client isn’t a browser. It carries no CF_Authorization cookie, so the native build’s connection to the WebSocket server is rejected at the edge with a 403 that looks nothing like an error from your own server. Browser tabs are fine because they already hold the cookie from logging in. For anything that isn’t a browser (the native app, a script, an agent calling a dev API) the answer is an Access service token, sent as two headers:

CF-Access-Client-Id:     <client_id>
CF-Access-Client-Secret: <client_secret>

The token grants nothing on its own. Access only honours it on apps whose policy names it, so its reach is exactly the list of dev hostnames and nothing wider. I file its policy under the non_identity decision rather than allow, which keeps it visible in the audit log as a bearer secret and not a person who logged in.

The stats the internet never sees

#

The other half of what I wanted was visibility. Most of what tells you how a system is behaving is, correctly, not public. On devbox that’s:

• the ingress proxy’s dashboard, and the tracing UI that holds its traces
• a dashboard for the Kubernetes cluster
• the container registry’s UI (read-only)
• Ollama’s model list and what’s loaded right now
• docker info and container stats

None of those have a public hostname, and none ever will. They’re bound to loopback or to cluster service IPs, reached over an SSH forward that itself rides the tunnel. A monitoring app on my phone reads docker info --format '{{json .}}' over SSH across WARP, so I can see from anywhere whether my containers are up or something has eaten all the memory.

That app is how I found a small bug worth mentioning. The tunnel sshd on the Mac was at LogLevel DEBUG2 from when I was debugging it. With -e, sshd logs to stderr, and for a session that stderr is the SSH channel’s stderr. Every command’s output came back with debug2: do_setup_env: set TMPDIR appended, and the phone app, which merges the two streams, got valid JSON followed by a log line, failed to parse it, and showed the whole thing as an error. LogLevel INFO fixed it. Put log levels back after debugging.

Just as deliberate is what I don’t put on this network. The old autossh tunnels also reach a few routers on other people’s networks that I help look after. Those get no public hostname and no WARP route. A router admin page on the internet is a liability even behind a login, and it isn’t my network to widen.

Access is not optional

#

A Cloudflare Tunnel hostname is on the public internet the moment its DNS record exists. There’s no firewall in front of it; that’s the whole point of not opening a port. The protection has to come from Cloudflare’s edge, and that’s what Access does. It refuses to forward a request at all until the visitor has proved who they are, so an unauthenticated scanner never reaches the laptop. That matters, because these are dev servers: a debug-mode traceback with settings in it, an open JavaScript bundler. Nothing behind these hostnames was built to face the internet.

The policy allows my own email addresses and nothing else, with a one-time PIN by email and single sign-on as the two ways to prove it. Sessions last eight hours, because the realistic threat is a laptop left open in a café with a day-long cookie, not someone brute-forcing a PIN.

SSH is authenticated twice, by two systems that don’t know about each other. Access decides whether a TCP stream may reach sshd at all; sshd still demands my key. Losing either doesn’t open the machine. The Mac’s tunnel sshd also trusts Cloudflare’s SSH CA, so Access can log me in with a short-lived certificate minted from my SSO session, while authorized_keys still works alongside it, so a broken Access config can’t lock me out of my own laptop.

The piece I’m happiest with is small. Exposure happens when three things line up: a DNS record, a running connector and an active zone. They become true at different times, in an order I don’t control; the zone flips to active on its own, some time after the nameservers change, quite possibly while the Mac is asleep. So the launch agent doesn’t run cloudflared directly. It runs a preflight that reads the hostnames out of the tunnel’s own config, asks the Access API which ones are covered, and refuses to start if any aren’t:

HOSTNAMES=$(grep -E '^\s*-\s*hostname:' "$CONFIG" | sed -E 's/.*hostname:\s*//' | sort -u)
PROTECTED=$(curl -fsS -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/access/apps?per_page=100" \
    | python3 -c 'import sys,json; print("\n".join(a.get("domain","") for a in json.load(sys.stdin)["result"]))') \
    || { echo "could not reach the Access API. refusing (fail closed)."; exit 1; }

for h in $HOSTNAMES; do
    grep -qxF "$h" <<<"$PROTECTED" || { echo "NOT starting: $h has no Access app"; exit 1; }
done
exec cloudflared tunnel --config "$CONFIG" run

The launch agent has KeepAlive, so a refusal retries by itself every 30 seconds and the tunnel comes up on its own once the Access apps exist. Failing closed costs an outage. Failing open costs an exposure. I know which of those I’d rather explain.

Four things that bit me

#

Everything above works now. Getting there, three of the four had the same pattern: the thing that was broken produced no error anywhere, and the parts I could see all reported healthy.

The route and the include list are two different lists. A tunnel route makes Cloudflare willing to carry an address to the right connector. The WARP include list is what makes the client send it in the first place. devbox was unreachable from the phone because its routes existed but the include list still only had the Mac’s addresses. The phone dropped the packets locally, the connector never saw a flow, and every dashboard was green. Every new machine means adding its addresses to both.

IPv4 literals on IPv6-only mobile networks. Covered above: works on wifi, fails on 5G, no error. If a WARP route works on wifi and not on mobile data, and the Agent shows connected, it’s routing, not the tunnel.

macOS sshd behind cloudflared. macOS starts its sshd with launchd socket activation, one short-lived sshd -i per connection. Behind cloudflared, the banner reaches the client and then the stream is torn down before the client’s identification string gets back, so every login dies at kex_exchange_identification. I confirmed it from both ends and reproduced it with a plain TCP relay, which ruled out Cloudflare. The fix is a second, standalone sshd -D on 127.0.0.1:2222 and the WARP loopback addresses, running as my user, that exists only to be the tunnel’s origin. Remote Login in System Settings is untouched. devbox, being Linux with a normal long-lived sshd, never had the problem.

Config fields that stop existing. Older examples have warp-routing: enabled: true in the tunnel config. cloudflared 2026.8 rejects that field outright. WARP routing is on whenever the block exists and a route points at the tunnel. That one at least produced an error, which after the other three felt almost generous.

What it changed

#

The honest summary is that I stopped choosing where to work based on where the hardware is. The laptop is a good keyboard and a good screen with a long battery life, and it doesn’t need to be more than that. The workstation does the heavy lifting from wherever I am. The phone is a real test device on a real network rather than something tethered to office wifi. And the parts of the system I use to see what it’s doing are one click away for me and don’t exist for anyone else.

At this size it fits in Cloudflare’s free Zero Trust plan. What it cost me was time and a README I’m glad I wrote, because every one of the failures above would have been a fresh mystery the second time.

If you’re thinking about something similar, these are the questions I’d ask of your setup:

1. What runs on your laptop only because the laptop is the one machine you can always reach?
2. Can your phone reach your dev server on mobile data, not just on the office wifi? Test it on 5G, not wifi.
3. Which of your dashboards are public because that was the easy way to see them from outside? Each one is a candidate for a private route instead.
4. If a tunnel hostname came up without its Access app tomorrow, what would stop it? If the answer is “I’d remember”, write the preflight.
5. Are your private addresses in a range the networks you visit will never use?

• SSH allows commands to be executed when somebody attempts to login. The following document will show you how to connect to Slack and control ssh order of execution

Webhook on Slack API

#

• Visit here to learn about creating an app.

• You will need to create a slack app, enable webhooks and create an incoming webhook for slack to receive notifications from SSH.

Creating the script for a failed attempt

#

• The following file can be saved anywhere on your system, I placed my file in /var/opt/notify-attempt.sh

#!/bin/bash
if [ "$PAM_TYPE" != "close_session" ]; then
        url="<YOUR SLACK WEBHOOK>"
        channel="#channel"
        host="$(hostname)"
        content="\"attachments\": [ { \"mrkdwn_in\": [\"text\", \"fallback\"], \"fallback\": \"SSH login: $PAM_USER connected to \`$host\`\", \"text\": \"SSH login to \`$host\`\", \"fields\": [ { \"title\": \"User\", \"value\": \"$PAM_USER\", \"short\": true }, { \"title\": \"IP Address\", \"value\": \"$PAM_RHOST\", \"short\": true } ], \"color\": \"#F35A00\" } ]"
        curl -X POST --data-urlencode "payload={\"channel\": \"$channel\", \"mrkdwn\": true, \"username\": \"SSH Notifications\", $content, \"icon_emoji\": \":inbox-tray:\"}" "$url" &
fi
exit

For other SSH events

#

• For other events such as successful login, I recommend creating two files.
• Each file will contain the correct JSON content that will be sent to Slack.
• You will need to edit the line fallback\": \"SSH login: $PAM_USER connected to \$host`"`
• You will see below where Openssh uses these scripts

Configuring ssh

#

I have commented out the successful attempt notification, you may uncomment it and execute the script to notify slack. This line:# auth optional pam_exec.so /var/opt/notify-login.sh

[success=2] means if the ssh login attempt is successful, it will jump two lines, hence skipping the failed attempt notification.

file: /etc/pam.d/common-auth

# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.
# here are the per-package modules (the "Primary" block)
auth  [success=2 default=ignore]   pam_unix.so nullok
auth  optional            pam_exec.so /var/opt/notify-attempt.sh
# here's the fallback if no module succeeds
auth  requisite            pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
# For successful login, uncomment the below line, ensure the file exists.
# auth  optional            pam_exec.so /var/opt/notify-login.sh
# auth  required            pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth  optional            pam_cap.so
# end of pam-auth-update config

Thank you!

#

• If you have any questions or comments please contact me directly