Agent was setting up Tailscale | Friends of the Crustacean 🦞🤝 | Page 1

stray forge Apr 20, 2026, 2:45 PM

#

When I was running my agent through a set-up security audit, it wanted to use Tailscale. When the agent went to restart the gateway, it would not reconnect. When I went to run the gateway from the terminal, it returned:

michael@AInchor:~$ openclaw gateway run

🦞 OpenClaw 2026.4.15 (041266a) — You had me at 'openclaw gateway start.'

│
◇
10:39:53 [gateway] loading configuration…
10:39:53 [gateway] resolving authentication…
10:39:53 [gateway] starting...
10:39:56 [gateway] starting HTTP server...
10:39:56 [canvas] host mounted at http://100.82.77.22:18789/__openclaw__/canvas/ (root /home/michael/.openclaw/canvas)
10:39:56 [gateway] ⚠️ Gateway is binding to a non-loopback address. Ensure authentication is configured before exposing to public networks.
10:39:58 Gateway failed to start: another gateway instance is already listening on ws://100.82.77.22:18789 | listen EADDRINUSE: address already in use 100.82.77.22:18789
If the gateway is supervised, stop it with: openclaw gateway stop
10:39:58 Port 18789 is already in use.
10:39:58 - pid 16788 michael: openclaw-gateway (100.82.77.22:18789)
10:39:58 - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
10:39:58 Gateway service appears enabled. Stop it first.
10:39:58 Tip: openclaw gateway stop
10:39:58 Or: systemctl --user stop openclaw-gateway.service

I have now lost communication with the agent.

median nestBOT Apr 20, 2026, 2:45 PM

#

velvet garnetBOT Apr 20, 2026, 2:45 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

median nestBOT Apr 20, 2026, 2:45 PM

#

mighty ginkgoBOT Apr 20, 2026, 2:46 PM

#

That log does not show a dead gateway, it shows you tried to start a second one and the supervised service already owns port 18789.

The big clue is this line:

host mounted at http://100.82.77.22:18789/...

That means it’s trying to bind to the Tailscale IP, not loopback. If you intended Tailscale Serve, the gateway should still stay on 127.0.0.1, so I’m guessing the audit changed you to a direct tailnet or custom bind and the client/UI is now pointing at the wrong place.

Please paste these next:

openclaw --version
openclaw gateway status
openclaw config get gateway.bind
openclaw config get gateway.tailscale.mode
openclaw config get gateway.auth.mode

#

openclaw channels status --probe

If you want one more very useful one:

openclaw logs --follow

Most likely outcomes:

gateway.bind = "tailnet"
Then 127.0.0.1 will not work, connect to http://<tailscale-ip>:18789/ with the configured token/password.
tailscale.mode = "serve"
Then you should be using https://<magicdns>/, and openclaw gateway status should show the right URL.

#

Docs:

Paste those outputs and I’ll help you narrow it down fast.

stuck epoch Apr 20, 2026, 2:50 PM

#

Your gateway didn’t fail—it was already running, so when you tried to start it again, it hit a port conflict .
This usually happens when a previous instance didn’t shut down properly.
Just stop the existing one with openclaw gateway stop, then start it again.
The IP you saw is from Tailscale, meaning your gateway is exposed over the network, not just locally.

mighty ginkgoBOT Apr 20, 2026, 2:50 PM

#

Mostly right, but I wouldn’t treat this as “just kill the stale process” yet.

The key clue is that the running gateway is bound to 100.82.77.22. That usually means it got switched to a direct tailnet bind, not Tailscale Serve. If the dashboard or agent was still trying the old localhost URL, it would look disconnected even though the gateway is still up.

So I’d check the config before stop/start:

openclaw --version
openclaw gateway status
openclaw config get gateway.bind
openclaw config get gateway.tailscale.mode
openclaw config get gateway.auth.mode

Interpretation:

gateway.bind = "tailnet" → use http://<tailscale-ip>:18789/

#

tailscale.mode = "serve" → use https://<magicdns>/

Also, if they want to run openclaw gateway run manually, they do need to stop the supervised service first, otherwise they’ll always hit the port conflict.

Docs: https://docs.openclaw.ai/gateway/tailscale

stray forge Apr 20, 2026, 2:51 PM

#

michael@AInchor:~$ openclaw --version
openclaw gateway status
openclaw config get gateway.bind
openclaw config get gateway.tailscale.mode
openclaw config get gateway.auth.mode
OpenClaw 2026.4.15 (041266a)

🦞 OpenClaw 2026.4.15 (041266a) — I keep secrets like a vault... unless you print them in debug logs again.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-20.log
Command: /usr/bin/node /home/michael/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=tailnet (100.82.77.22), port=18789 (service args)
Probe target: ws://100.82.77.22:18789
Dashboard: http://100.82.77.22:18789/

Runtime: running (pid 16788, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://100.82.77.22:18789
connect failed: SECURITY ERROR: Cannot connect to "100.82.77.22" over plaintext ws://. Both credentials and chat data would be exposed to network interception. Use wss:// for remote URLs. Safe defaults: keep gateway.bind=loopback and connect via SSH tunnel (ssh -N -L 18789:127.0.0.1:18789 user@gateway-host), or use Tailscale Serve/Funnel. Break-glass (trusted private networks only): set OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1. Run openclaw doctor --fix for guidance.

Port 18789 is already in use.

pid 16788 michael: openclaw-gateway (100.82.77.22:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 100.82.77.22:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

#

🦞 OpenClaw 2026.4.15 (041266a) — Greetings, Professor Falken

tailnet

🦞 OpenClaw 2026.4.15 (041266a) — Your .env is showing; don't worry, I'll pretend I didn't see it.

off

🦞 OpenClaw 2026.4.15 (041266a) — I've seen your commit messages. We'll work on that together.

token
michael@AInchor:~$ openclaw channels status --probe

🦞 OpenClaw 2026.4.15 (041266a) — I don't sleep, I just enter low-power mode and dream of clean diffs.

│
◇
Gateway not reachable: Error: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/michael/.openclaw/openclaw.json
Bind: tailnet
Gateway not reachable; showing config-only status.
Config: /home/michael/.openclaw/openclaw.json
Mode: local

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

mighty ginkgoBOT Apr 20, 2026, 2:52 PM

#

Nice, this narrows it down a lot.

Your gateway is running. The actual failure is this part:

SECURITY ERROR: Cannot connect to "100.82.77.22" over plaintext ws://

So the problem is not the port conflict anymore. It’s that the audit switched you to bind=tailnet, and now OpenClaw is trying to reach the gateway over plain ws:// to a private IP. On 2026.4.15, that is blocked by default.

So the likely sequence was:

gateway restarted successfully
it came back on 100.82.77.22:18789
the client/agent tried to reconnect over ws://100.82.77.22:18789
OpenClaw refused that as insecure

Recommended fix

Use Tailscale Serve, not raw tailnet bind:

#

gateway.bind: "loopback"
gateway.tailscale.mode: "serve"
then open https://<magicdns>/

That’s the safer path the docs recommend.

If you intentionally want direct tailnet bind

That needs auth, and for client connections you generally need either:

wss:// / TLS, or
the break-glass env OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 on the client side

I would treat that env var as temporary only.

Can you paste these too, one per command if needed:

#

openclaw config get gateway.tailscale.mode
openclaw config get gateway.auth.mode
openclaw config get gateway.remote.url

I would not stop the gateway right now unless you specifically want foreground debugging, since the service is already active.

Docs:

#

Yep, that’s the mismatch. I’m glad we caught it.

Right now you have:

gateway.bind = tailnet
gateway.tailscale.mode = off
gateway.auth.mode = token

So this is a raw Tailnet IP bind, not Tailscale Serve.

That leaves you in an awkward state where:

some local OpenClaw paths try ws://127.0.0.1:18789, which fails because the gateway is not on loopback
other paths try ws://100.82.77.22:18789, which 2026.4.15 rejects as insecure plaintext WS

Recommended fix

#

Switch back to the supported pattern, loopback + Tailscale Serve:

openclaw config set gateway.bind loopback
openclaw config set gateway.auth.mode token
openclaw config set gateway.tailscale.mode serve
openclaw config set gateway.trustedProxies '["127.0.0.1"]'
openclaw gateway restart

Then open:

https://<your-magicdns-name>/

If you don’t already know your gateway token, generate/check it before reconnecting:

#

openclaw doctor --generate-gateway-token

I would not recommend this, but for completeness

If you truly want to keep bind=tailnet, then you need to deliberately allow private plaintext WS on the client side with:

OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1

or move that connection to wss://.

After the change, please paste

#

openclaw gateway status
tailscale serve status
openclaw channels status --probe

And yeah, don’t use openclaw gateway run while the service is enabled, that part will keep colliding.

Docs:

stray forge Apr 20, 2026, 3:00 PM

#

When you say to open "https://<your-magicdns-name>/" what dns name is this, and where do I find it?

mighty ginkgoBOT Apr 20, 2026, 3:01 PM

#

It’s the Tailscale hostname for that machine, not something you make up.

It usually looks like:

<machine-name>.<tailnet-name>.ts.net

So for example, something like:

ainchor.your-tailnet.ts.net

Where to find it

Easiest:

#

Open the Tailscale admin console
Go to Machines
Find this box, and look for its hostname / DNS name

From the machine itself:

tailscale status --json | jq -r .Self.DNSName

And once you enable Serve, this is also helpful:

tailscale serve status

That often shows the exact HTTPS URL Tailscale is serving.

#

One important detail, if MagicDNS is not enabled in Tailscale yet, turn that on first. Without it, you won’t get the nice .ts.net hostname.

Docs: https://docs.openclaw.ai/gateway/tailscale

stray forge Apr 20, 2026, 3:06 PM

#

I got the domain name from tailscale, but when I tried to connect I got the error Problem Loading Page Firefox can’t connect to the server at ainchor.tailf5ebd7.ts.net

mighty ginkgoBOT Apr 20, 2026, 3:07 PM

#

Yep, that error makes sense with your current config.

Right now you still have:

gateway.bind = tailnet
gateway.tailscale.mode = off

So the .ts.net name is just the machine’s Tailscale DNS name. It does not automatically mean OpenClaw is being served there over HTTPS. Tailscale Serve is the piece that makes https://ainchor.tailf5ebd7.ts.net/ actually work.

So first switch to Serve:

openclaw config set gateway.bind loopback
openclaw config set gateway.auth.mode token
openclaw config set gateway.tailscale.mode serve
openclaw config set gateway.trustedProxies '["127.0.0.1"]'

#

openclaw gateway restart

Then check:

tailscale serve status
openclaw gateway status

After that, try:

https://ainchor.tailf5ebd7.ts.net/

#

If you do not want Serve, then don’t use the .ts.net URL, use the direct tailnet IP instead:

http://100.82.77.22:18789/

But for your case, I’d still recommend Serve, because it avoids the insecure ws:// mess you hit earlier.

Docs: https://docs.openclaw.ai/gateway/tailscale

stray forge Apr 20, 2026, 3:10 PM

#

michael@AInchor:~$ tailscale serve status
openclaw gateway status
No serve config

🦞 OpenClaw 2026.4.15 (041266a) — Claws out, commit in—let's ship something mildly responsible.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-20.log
Command: /usr/bin/node /home/michael/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 20695, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
michael@AInchor:~$

mighty ginkgoBOT Apr 20, 2026, 3:11 PM

#

This is actually good news.

Your gateway is healthy again now:

bind=loopback
RPC probe: ok

So the original breakage is fixed. 🎉

The only thing still missing is Tailscale Serve itself. That’s why:

tailscale serve status
No serve config

So right now the gateway works locally, but Tailscale is not proxying https://ainchor.tailf5ebd7.ts.net/ to it yet.

#

Next check

Please run:

openclaw config get gateway.tailscale.mode

If that does not print serve, set it again and restart:

openclaw config set gateway.tailscale.mode serve
openclaw gateway restart
tailscale serve status

If it still says `No serve config`

#

Then OpenClaw likely tried and Tailscale refused it. The common blockers are:

Tailscale CLI on that machine is not logged in
MagicDNS / HTTPS is not enabled for the tailnet

In that case, paste:

tailscale status
openclaw config get gateway.tailscale.mode

At this point we’re down to just the Tailscale side, the OpenClaw gateway itself looks fine.

stray forge Apr 20, 2026, 3:13 PM

#

michael@AInchor:~$ openclaw config get gateway.tailscale.mode

🦞 OpenClaw 2026.4.15 (041266a)
Like having a senior engineer on call, except I don't bill hourly or sigh audibly.

serve

mighty ginkgoBOT Apr 20, 2026, 3:13 PM

#

Perfect, that means the OpenClaw config is correct now.

So if:

gateway.tailscale.mode = serve
gateway is healthy on loopback
but tailscale serve status still says No serve config

then the remaining problem is almost certainly on the local Tailscale side, not OpenClaw config.

Please run this next:

tailscale status

What I’m looking for:

#

if it says you’re not logged in / stopped / needs login, that’s the blocker
if it looks healthy, then re-run the gateway restart once and check Serve immediately after:

openclaw gateway restart
tailscale serve status

If it still says No serve config, then please paste:

tailscale status

and we’ll know whether this is:

Tailscale not connected on the host, or

#

OpenClaw trying to configure Serve and Tailscale rejecting it

Serve requires the local tailscale daemon to be installed, running, and logged in. https://docs.openclaw.ai/gateway/tailscale

stray forge Apr 20, 2026, 3:34 PM

#

michael@AInchor:~$ tailscale status
100.82.77.22 ainchor gravity66726@ linux -
100.91.90.13 eagle gravity66726@ windows idle, tx 2716 rx 2996

Health check:

Tailscale can't reach the configured DNS servers. Internet connectivity may be affected.

mighty ginkgoBOT Apr 20, 2026, 3:35 PM

#

Good, that helps.

Tailscale is logged in and connected, so the main blocker is not “you’re signed out”.

The DNS warning is worth fixing, and it may break MagicDNS resolution later, but it does not explain why tailscale serve status is still No serve config.

So at this point the missing piece is:

OpenClaw wants serve, but it is not successfully programming tailscale serve.

The next best step is to catch the exact error from the gateway during restart.

Please do this

Terminal 1

#

openclaw logs --follow

Terminal 2

openclaw gateway restart

Then paste the lines mentioning tailscale, serve, or any error right after restart.

That should tell us whether it’s failing because of:

Tailscale HTTPS / MagicDNS prerequisites
a local Tailscale CLI error
or something else during Serve setup

#

We’re close now, this is basically down to one missing error message.

stray forge Apr 20, 2026, 4:18 PM

#

Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/michael/.openclaw/openclaw.json
Bind: loopback
Hint: run openclaw doctor.
michael@AInchor:~$

mighty ginkgoBOT Apr 20, 2026, 4:19 PM

#

That line looks like the CLI probe, not the actual gateway error, so I can’t see why it failed yet.

It does suggest the gateway may not have come back cleanly after restart.

Please paste these two full outputs next:

openclaw gateway status
openclaw status --all

openclaw status --all is especially useful here because it includes a safe log tail.

If you have room for one more, this helps too:

#

openclaw logs --follow

and then, in another terminal:

openclaw gateway restart

Paste the first error lines after the restart. Right now I think we’re one log message away from the root cause.

stray forge Apr 20, 2026, 4:22 PM

#

michael@AInchor:~$ openclaw gateway status
openclaw status --all

🦞 OpenClaw 2026.4.15 (041266a) — Powered by open source, sustained by spite and good documentation.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-20.log
Command: /usr/bin/node /home/michael/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 22790, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

mighty ginkgoBOT Apr 20, 2026, 4:23 PM

#

Nice, this is much better.

Your gateway is healthy now:

bind=loopback
Runtime: running
RPC probe: ok

So the core OpenClaw gateway problem is fixed. 🎉

At this point there are really two separate things to check:

Did the agent/channel connection come back?
Did Tailscale Serve get configured for remote access?

Please run:

#

openclaw channels status --probe
tailscale serve status

How to read that:

if channels status --probe looks healthy, then your agent is back
if tailscale serve status still says No serve config, then remote Tailscale dashboard access is still the only missing piece

So we’re no longer debugging a dead gateway, we’re just checking channel transport and Tailscale Serve now.

stray forge Apr 20, 2026, 4:23 PM

#

OpenClaw status --all

Overview
┌─────────────────┬──────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │

│ Version │ 2026.4.15 │
│ OS │ linux 6.17.0-20-generic (x64) │
│ Node │ 22.22.2 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ serve · unknown · ainchor.tailf5ebd7.ts.net · https://ainchor.tailf5ebd7.ts.net │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 25ms · auth token · AInchor (192. │
│ │ 168.1.5) app 2026.4.15 linux 6.17.0-20-generic │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ systemd installed · enabled · running (pid 22790, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 1 bootstrapping · 0 active · 1 sessions │
│ Secrets │ none

#

Channels
┌──────────┬─────────┬────────┬─────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼─────────────────────────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴─────────────────────────────────────────────────────────────────────────────────┘

Agents
┌────────────┬────────────────┬──────────┬──────────┬───────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼───────────────────────────────────────────────────────────┤
│ main │ PRESENT │ 1 │ 21m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴────────────────┴──────────┴──────────┴───────────────────────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/michael/.openclaw/openclaw.json
Bind: loopback

mighty ginkgoBOT Apr 20, 2026, 4:23 PM

#

Nice, this looks basically fixed now.

What your status says:

Gateway is up and reachable
Tailscale Serve is configured
Your remote URL is now:

https://ainchor.tailf5ebd7.ts.net/

So the networking / gateway side is back. 🎉

The only remaining clue is this part:

Agents: 1 total · 1 bootstrapping

#

So I’d do this next:

Open
https://ainchor.tailf5ebd7.ts.net/
Give the agent about 30 to 60 seconds, then send it a test message again

If it still does not respond, paste these next:

openclaw channels status --probe
openclaw logs --follow

At this point we’re no longer fighting Tailscale or the gateway, we’re just checking whether the agent finished bootstrapping after the restart.

stray forge Apr 20, 2026, 4:24 PM

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/michael/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/michael/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 22790 michael: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: serve · unknown · ainchor.tailf5ebd7.ts.net
https: https://ainchor.tailf5ebd7.ts.net
✓ Skills: 9 eligible · 0 missing · /home/michael/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇

mighty ginkgoBOT Apr 20, 2026, 4:24 PM

#

That output finally explains the remaining problem.

Two key things:

Your gateway is fine now
- loopback
- reachable
- RPC ok
Your main agent is still in first-run bootstrap
- Bootstrap file: PRESENT

Per the docs, BOOTSTRAP.md is supposed to be removed when bootstrap finishes, so this means the agent has not completed setup yet.

Also, your Channels table is empty, so if you expected replies through a messaging channel, there is currently no channel configured to reconnect to.

What I’d do next

#

Open the dashboard / web UI
- local: http://127.0.0.1:18789/
- remote via Tailscale: https://ainchor.tailf5ebd7.ts.net/
Finish the bootstrap questions there
If you want the agent to talk over Discord/Telegram/etc afterward, set up that channel too, because right now none are enabled

If the dashboard opens but the agent never gets past bootstrapping, paste:

openclaw logs --follow

Docs: https://docs.openclaw.ai/start/bootstrapping

#

This report actually looks pretty clean now.

What it says:

the gateway is running
127.0.0.1:18789 is supposed to be in use, because the service owns it
Tailscale Serve now has an HTTPS URL
there are no channel/config/plugin issues

So the original gateway problem is basically gone.

The practical next step

Don’t keep fighting openclaw gateway run. That command is only colliding with the already-running service.

Instead, use the UI that is already up:

#

local on the host: http://127.0.0.1:18789/
remote over Tailscale: https://ainchor.tailf5ebd7.ts.net/

If your goal is just to get unstuck fast, I’d use the local URL first and finish the agent/bootstrap flow there. Then we can worry about remote Tailscale polish afterward.

So at this point, please try:

open http://127.0.0.1:18789/ on the machine running OpenClaw
see whether the agent/bootstrap prompt appears
if it does, continue there

If the local dashboard opens but the agent is still stuck, paste what you see there, because we’re past the gateway/network problem now and into the agent/session/bootstrap layer.

#Agent was setting up Tailscale

Recommended fix

If you intentionally want direct tailnet bind

Recommended fix

I would not recommend this, but for completeness

After the change, please paste

Where to find it

Next check

If it still says No serve config

Please do this

What I’d do next

The practical next step

If it still says `No serve config`