I got OpenClaw working on my phone, Mac, and Windows box — then NetBird became the real project

I thought the hard part would be getting OpenClaw running across devices.

It wasn’t.

The hard part was everything after the first successful demo.

I had OpenClaw visible on my phone and desktop. For about five minutes, it felt finished. Then the iPhone couldn’t see the home node. The Windows companion app got weird. A broken Mac install ate the rest of the night.

That changed my opinion fast:

If your OpenClaw setup depends on flaky peer-to-peer networking, model quality is not your bottleneck.

Fix NetBird or Tailscale-class connectivity first, or stop calling the agent stack production-ready.

While digging into this, I found a few r/openclaw threads that perfectly captured the pattern:

• OpenClaw on Android, any phone, or computer
• NetBird + OpenClaw on iOS
• Is anyone using the Windows OpenClaw Companion App?

The screenshots look great. The architecture story usually doesn’t.

The real problem starts after the first screenshot

Cross-device AI demos hide infrastructure debt.

The first stage always feels good:

1. Get OpenClaw running on one machine
2. Expose it to another device
3. See the UI load
4. Declare victory way too early

Then reality shows up:

• iOS can’t consistently reach the node
• Windows needs a workaround
• macOS install state drifts or breaks
• reconnect behavior is fuzzy
• nobody knows what recovery looks like after sleep, reboot, or network changes

At that point, the agent is not the project anymore.

Networking is the project.

And that matters because better prompts won’t fix an unreachable node. Claude Opus 4.6 won’t help if your phone can’t connect. GPT-5.4 won’t rescue a broken tunnel.

My rule now: fix connectivity before prompts, models, or UX

If you’re just experimenting on one machine, weirdness is fine.

If you want always-on agents running through OpenClaw, n8n, Make, Zapier, or a custom workflow, the order of operations matters a lot more than people admit.

Here’s the order I’d use:

1. Connectivity
2. Recovery
3. Compute
4. Prompts, tools, UX, polish

That order sounds boring. It is also the difference between a toy and a system.

What “good enough” connectivity actually looks like

Before touching prompt tuning, I want answers to these:

• Can every client device reach the node reliably?
• Does reconnect happen automatically after sleep/wake?
• What breaks when the home IP changes?
• What breaks when the phone switches Wi‑Fi to cellular?
• What’s the recovery path after a reboot?
• Can I detect failure, or does it just silently stop working?

If you don’t have those answers, you’re not optimizing an agent stack yet. You’re still proving the access path.

A practical checklist for OpenClaw across phone, Mac, and Windows

This is the checklist I wish I had used first.

1) Verify the tunnel before opening OpenClaw

Don’t start with the app UI. Start with network reachability.

# Can I resolve the peer?
ping my-openclaw-node

# Is the service port reachable?
nc -vz my-openclaw-node 3000

# Can I hit the app directly?
curl http://my-openclaw-node:3000/health

If these fail, OpenClaw is not the problem yet.

2) Test from every client separately

Don’t assume “works on Mac” means “works everywhere.”

Test each of these independently:

• iPhone on Wi‑Fi
• iPhone on cellular
• Windows laptop on home network
• Windows laptop offsite
• Mac after sleep/wake

Different clients fail in different ways. That’s normal. Pretending they don’t is how you lose an evening.

3) Check the tunnel state first

Whether you use NetBird or Tailscale, check the overlay network before touching the app.

Example flow:

# NetBird status example
netbird status

# Tailscale status example
tailscale status

What I care about:

• peer visible
• peer authenticated
• routes active
• no stale sessions
• no relayed fallback when direct connectivity should exist

4) Add a dead-simple health endpoint

If your stack doesn’t expose one, add a tiny health check in front of it.

curl -f http://localhost:3000/health || echo "unhealthy"

For automations, this matters more than people think. You want a machine-checkable signal, not “it loaded for me once.”

5) Treat sleep/reboot as first-class test cases

A lot of “works on my machine” setups fail here.

Test this sequence explicitly:

1. Start OpenClaw
2. Confirm tunnel connectivity
3. Put laptop to sleep
4. Wake laptop
5. Switch networks
6. Retry health check
7. Retry from phone

If step 7 fails often, you don’t have an always-on setup.

Why this gets worse once you automate anything

The failure mode is not dramatic. That’s what makes it dangerous.

With automations, flaky connectivity creates silent unreliability:

• webhook fires, but agent is unreachable
• session starts, then stalls halfway through
• retry logic burns time against a dead node
• scheduled jobs “run” but don’t actually complete useful work

That’s much worse than a hard failure.

Hard failures get fixed.
Silent failures sit in production and waste your week.

The Windows companion app question says a lot

That r/openclaw thread asking whether anyone is using the Windows OpenClaw Companion App is revealing on its own.

When the companion app is still a point of uncertainty, you are not in the prompt-optimization phase. You are still validating basic system behavior.

That’s not a criticism of OpenClaw specifically. It’s just the reality of local-first, multi-device stacks:

• networking quirks become product issues
• OS-specific behavior becomes maintenance work
• updates become risk
• “remote access” stops being a feature and becomes the core dependency

My blunt take on local-first OpenClaw

I like local-first OpenClaw for experimentation.

I do not think it should be the default choice for always-on automations.

If your goal is:

• personal workflows
• interface experiments
• testing agent behavior locally
• hacking on a setup for fun

then local-first is great.

If your goal is:

• 24/7 agents
• production automations
• webhook-driven workflows
• multi-step jobs in n8n, Make, or Zapier
• custom agents that need stable API access

then local-first often creates more ops burden than people budget for.

What I’d use instead for always-on agent workloads

For reliable automations, I’d rather have:

• boring, stable API access
• OpenAI-compatible endpoints
• predictable monthly cost
• no per-token babysitting
• infrastructure that doesn’t depend on whether my laptop woke up correctly

This is where Standard Compute fits the stack well.

If your agents already speak the OpenAI API, Standard Compute is a drop-in replacement with flat monthly pricing. That matters once your workflows stop being occasional and start running continuously.

When connectivity is finally stable, usage goes up fast:

• more retries
• more background jobs
• more chained calls
• less hesitation about token burn

That’s exactly when per-token pricing gets annoying.

With Standard Compute, the tradeoff is simpler: get stable access, let the automations run, and stop watching token counters all day.

Example: moving from a local-only mindset to a stable automation path

A lot of teams start here:

Phone -> NetBird/Tailscale -> Home machine -> OpenClaw -> LLM

That’s fine for experimentation.

But for always-on workflows, this is usually cleaner:

n8n / Make / Zapier / custom app
        -> OpenAI-compatible API
        -> model routing + compute layer
        -> agent logic stays reachable 24/7

That second path is less fun to show in screenshots.

It’s also much better when the webhook fires at 3:12 AM and nobody wants to debug a sleeping MacBook.

Quick decision framework

Use this if you’re deciding whether to keep investing in a local-first OpenClaw setup.

What I’d do if I were starting over tonight

I’d spend the first hour on networking validation, not prompts.

I’d make myself prove these five things:

[ ] iPhone can reach the node reliably
[ ] Windows can reconnect cleanly
[ ] Mac survives sleep/wake and reboot
[ ] health endpoint is scriptable
[ ] failure is detectable by automation

Only after that would I care about model selection, prompt quality, or UX polish.

And if the real goal was always-on automation, I’d probably skip the local-first hero setup entirely and move to stable API-based infrastructure sooner.

Final opinion

My setup looked impressive right before it became a networking problem.

That’s the trap.

A lot of OpenClaw stacks feel “almost done” because the first screenshot works. But if iOS reachability is flaky, Windows needs special handling, and macOS maintenance is eating your night, the architecture is telling you something.

You’re not optimizing an agent.

You’re still building a reliable path to the agent.

And for always-on automations, that path matters more than any prompt ever will.