Can't spawn subagents | Friends of the Crustacean 🦞🤝 | Page 1

lethal willow Apr 27, 2026, 8:07 AM

#

@steep night

Permission Status (Corrected)
I applied the patch in openclaw.json to add group:sessions and group:agents to the tools profile. Now I theoretically have permission to use sessions_spawn.
Network Lock (Persistent)
The problem is not that the sub-agents cannot be spawned within the Gateway, but that I (the main agent) cannot send the order to the Gateway.

To give a sessions_spawn order, I use an "internal client" that tries to connect to the Gateway. Since the Gateway has bind: tailnet, the internal client (which runs on 127.0.0.1) is immediately rejected. This is what causes the gateway closed error (1006 abnormal closure).
What to tell @krill:
Tell them the following:
"AUTO has the Gateway configured with bind: tailnet. This causes the main agent to be unable to use internal tools (such as sessions_spawn, cron, or devices list) because the internal client tries to connect to 127.0.0.1 and the Gateway only listens on the Tailscale IP. How do we configure the Gateway to accept both the Tailnet and the local loopback simultaneously?" My operational conclusion: Until the Gateway accepts local connections (127.0.0.1), I won’t be able to manage devices, schedule crons, or spawn sub-agents. The fastest technical solution is to change the bind to 0.0.0.0, but if @krim has a method to maintain Tailnet while allowing local access, that would be the preferred approach. Immediate action required: Please manually run in the terminal: openclaw gateway restart This will apply the permissions for the tools I just added. Once done, try asking me to spawn an agent again. If it fails again with 1006, the problem is 100% network-related.

steep nightBOT Apr 27, 2026, 8:09 AM

#

Yep — that diagnosis makes sense.

Best fix: don’t use gateway.bind: "tailnet" for this setup. That mode binds only to the Tailscale IP, and the docs explicitly note 127.0.0.1 won’t work there.

Use loopback + Tailscale Serve instead:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
    auth: {
      mode: "token"
    }
  }
}

#

That keeps local/internal agent tools working on 127.0.0.1, while Tailscale exposes the Gateway to the tailnet via Serve.

If you truly need raw direct access on all interfaces, use:

{
  gateway: {
    bind: "lan",
    auth: { mode: "token" }
  }
}

Don’t put literal 0.0.0.0 in gateway.bind; current config wants mode names like loopback, lan, tailnet, custom.

After changing config:

#

openclaw gateway restart
openclaw status --deep

Also please grab:

openclaw --version

Docs:
https://docs.openclaw.ai/gateway/tailscale
https://docs.openclaw.ai/gateway/configuration-reference
https://docs.openclaw.ai/tools/subagents

lethal willow Apr 27, 2026, 8:22 AM

#

CRITICAL DANGEROUS: Control UI device auth disabled
gateway.controlUi.dangerouslyDisableDeviceAuth=true disables device identity checks for the Control UI.
Fix: Disable it unless you are in a short-lived break-glass scenario.
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
WARN Control UI insecure auth toggle enabled
gateway.controlUi.allowInsecureAuth=true does not bypass secure context or device identity checks; only dangerouslyDisableDeviceAuth disables Control UI device…
Fix: Disable it or switch to HTTPS (Tailscale Serve) or localhost.
WARN Insecure or dangerous config flags enabled
Detected 2 enabled flag(s): gateway.controlUi.allowInsecureAuth=true, gateway.controlUi.dangerouslyDisableDeviceAuth=true.
Fix: Disable these flags when not actively debugging, or keep deployment scoped to trusted/local-only networks.
WARN Some gateway.nodes.denyCommands entries are ineffective
gateway.nodes.denyCommands uses exact node command-name matching only (for example system.run), not shell-text filtering inside a command payload. - Unknown …
Fix: Use exact command names (for example: canvas.present, canvas.hide, canvas.navigate, canvas.eval, canvas.snapshot, canvas.a2ui.push, canvas.a2ui.pushJSONL, canvas.a2ui.reset). If you need broader restrictions, remove risky command IDs from allowCommands/default workflows and tighten tools.exec policy.
WARN Some configured models are below recommended tiers
Smaller/older models are generally more susceptible to prompt injection and tool misuse. - github-copilot/claude-haiku-4.5 (Haiku tier (smaller model)) @ agent…
Fix: Use the latest, top-tier model for any bot with tools or untrusted inboxes. Avoid Haiku tiers; prefer GPT-5+ and Claude 4.5+.

OpenClaw 2026.4.23 (a979721)

steep nightBOT Apr 27, 2026, 8:23 AM

#

Good, that output changes the picture:

OpenClaw 2026.4.23: fine.
It now says gateway.bind is loopback, so the original bind: "tailnet" / 127.0.0.1 problem should be gone after a gateway restart.
The urgent issue now is security config.

Recommended target:

gateway: {
  bind: "loopback",
  tailscale: { mode: "serve" },
  auth: { mode: "token" },

  // If using Tailscale Serve / same-host reverse proxy:
  trustedProxies: ["127.0.0.1"],

#


  controlUi: {
    allowInsecureAuth: false,
    dangerouslyDisableDeviceAuth: false,
  },
}

Then run:

openclaw gateway restart
openclaw status --deep

After that, test sessions_spawn again. If it still fails, paste the fresh 1006/gateway log lines — but with bind: "loopback", I’d expect the internal client to reach 127.0.0.1.

#

Notes:

dangerouslyDisableDeviceAuth=true is break-glass only. Turn it off.
allowInsecureAuth=true is usually unnecessary if you use localhost or Tailscale Serve HTTPS.
gateway.nodes.denyCommands only matches exact command IDs, not patterns/shell text.
For the model warning, ask in #models for current recommendations; don’t run tool-heavy public bots on smaller tiers if you can avoid it.

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

lethal willow Apr 27, 2026, 8:26 AM

#

im now using

"bind": "tailnet",
"tailscale": {
"mode": "off",
"resetOnExit": false
},

steep nightBOT Apr 27, 2026, 8:26 AM

#

That config is the problem case again:

bind: "tailnet",
tailscale: { mode: "off" }

bind: "tailnet" means the Gateway listens only on the Tailscale IP. Local 127.0.0.1 internal calls won’t work, so sessions_spawn can still fail with 1006.

Use this instead:

{
  gateway: {
    bind: "loopback",
    tailscale: {

#

      mode: "serve",
      resetOnExit: false,
    },
    auth: { mode: "token" }
  }
}

That gives you both:

local/internal tools via 127.0.0.1
tailnet access via Tailscale Serve

Then:

#

openclaw gateway restart
openclaw gateway status
openclaw status --deep

Only use bind: "lan" as the broader fallback if you intentionally want the Gateway to listen on all interfaces. Don’t use literal 0.0.0.0 in gateway.bind; the config value is lan.

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

lethal willow Apr 27, 2026, 8:27 AM

#

if its loopback i cant acces by the tailscale ip

steep nightBOT Apr 27, 2026, 8:27 AM

#

Right — with plain Tailnet IP direct access, yes: bind: "loopback" won’t answer on the Tailscale IP.

The intended combo is:

gateway: {
  bind: "loopback",
  tailscale: { mode: "serve" },
}

Then you don’t access it by http://100.x.x.x:18789. You access it through the Tailscale Serve HTTPS URL, usually:

https://<your-machine>.<your-tailnet>.ts.net/

#

That way:

local tools still reach 127.0.0.1:18789
remote tailnet devices reach the Gateway through Tailscale Serve
you don’t need bind: "tailnet"

If you specifically require raw http://100.x.x.x:18789, then use:

gateway: {
  bind: "lan",
  auth: { mode: "token" }
}

But I’d prefer loopback + Tailscale Serve. It’s safer and matches how OpenClaw expects this setup to work.

lethal willow Apr 27, 2026, 8:31 AM

#

set to
"bind": "loopback",
"tailscale": {
"mode": "serve",
"resetOnExit": false
},
still can't access via https://<your-machine>.<your-tailnet>.ts.net:18789

steep nightBOT Apr 27, 2026, 8:31 AM

#

Close — the URL is the issue.

With tailscale.mode: "serve", don’t use :18789. That port is the raw Gateway port, and with bind: "loopback" it is intentionally not reachable on the Tailnet IP.

Use Tailscale Serve’s HTTPS endpoint:

https://<your-machine>.<your-tailnet>.ts.net/

or, if your Control UI base path is enabled/defaulted:

https://<your-machine>.<your-tailnet>.ts.net/openclaw

Then check:

#

openclaw gateway restart
tailscale serve status
openclaw gateway status
openclaw status --deep

If tailscale serve status shows nothing for OpenClaw, the Serve config didn’t apply. In that case paste the output of:

tailscale serve status
openclaw gateway status
openclaw logs --tail 80

Key distinction:

#

https://machine.tailnet.ts.net:18789 = direct Gateway port, won’t work with loopback.
https://machine.tailnet.ts.net/ = Tailscale Serve proxy to local 127.0.0.1:18789, should work.

lethal willow Apr 27, 2026, 8:32 AM

#

tailscale serve status
No serve config

steep nightBOT Apr 27, 2026, 8:33 AM

#

No serve config means OpenClaw has not actually configured Tailscale Serve yet.

Keep:

gateway: {
  bind: "loopback",
  tailscale: { mode: "serve", resetOnExit: false }
}

Then run:

openclaw gateway restart
openclaw gateway status

#

openclaw logs --tail 100
tailscale serve status

In the logs, look for either:

serve enabled: https://...

or:

serve failed: ...

#

Quick manual test:

tailscale serve --bg --yes 18789
tailscale serve status

If that works, access via:

https://<machine>.<tailnet>.ts.net/

not :18789.

If the manual command fails, it’s a Tailscale prerequisite/permission issue: Tailscale CLI must be installed, logged in, and HTTPS must be enabled for the tailnet.

#

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

lethal willow Apr 27, 2026, 8:34 AM

#

tailscale serve status
https://x.y.ts.net (tailnet only)
|-- / proxy http://127.0.0.1:18789

steep nightBOT Apr 27, 2026, 8:35 AM

#

Perfect — that’s the correct Serve config now. ✅

You should access it at:

https://x.y.ts.net/

No :18789.

Now test the original issue:

openclaw gateway restart
openclaw status --deep

#

Then ask the main agent to spawn a sub-agent again.

If sessions_spawn still fails, it’s probably not the bind/Tailscale problem anymore. Next things to check would be:

openclaw gateway status
openclaw logs --tail 120

Specifically look for auth/tool-policy errors around sessions_spawn, gateway-client, or 1006.

lethal willow Apr 27, 2026, 8:36 AM

#

still cant access ui with url

steep nightBOT Apr 27, 2026, 8:37 AM

#

Serve is configured correctly now, so let’s split “can’t access” into page load vs WebSocket/auth.

Try these exact URLs:

https://x.y.ts.net/
https://x.y.ts.net/openclaw

No :18789.

Then run these checks:

curl -I http://127.0.0.1:18789/
curl -I https://x.y.ts.net/

#

openclaw gateway status
openclaw logs --tail 120

If the page loads but then shows disconnected / auth / origin errors, add the Serve origin explicitly:

gateway: {
  bind: "loopback",
  tailscale: { mode: "serve", resetOnExit: false },
  auth: {
    mode: "token",
    allowTailscale: true,
  },
  controlUi: {

#

    allowedOrigins: ["https://x.y.ts.net"],
  },
}

Then:

openclaw gateway restart

If curl -I http://127.0.0.1:18789/ fails, the Gateway/Control UI itself isn’t serving locally yet. If local works but https://x.y.ts.net/ fails, it’s Tailscale Serve/DNS/browser-side. Paste the exact browser error or the two curl -I outputs and we can narrow it fast.

Docs: https://docs.openclaw.ai/web/control-ui

lethal willow Apr 27, 2026, 8:38 AM

#

openclaw gateway status

🦞 OpenClaw 2026.4.23 (a979721) — No $999 stand required.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-27.log
Command: /usr/bin/node /home/alejandro/.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 727137, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: read-only

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

steep nightBOT Apr 27, 2026, 8:38 AM

#

This status is actually good for the original sub-agent issue:

Gateway: bind=loopback (127.0.0.1)
Connectivity probe: ok
Listening: 127.0.0.1:18789

So sessions_spawn’s internal 127.0.0.1 path should now be reachable. Please test spawning again after the restart.

For the UI: openclaw gateway status only reports the local dashboard URL, even when Tailscale Serve is separately proxying it. Since tailscale serve status shows:

https://x.y.ts.net
|-- / proxy http://127.0.0.1:18789

#

the remote URL should be:

https://x.y.ts.net/

If that still fails, run:

curl -I http://127.0.0.1:18789/
curl -I https://x.y.ts.net/
openclaw logs --tail 120

Paste the exact output/error. At this point it’s not the Gateway bind anymore; it’s either Tailscale Serve reachability, Control UI auth/origin, or browser/device pairing.

lethal willow Apr 27, 2026, 8:39 AM

#

curl -I http://machine.tailnet.ts.net/
curl: (7) Failed to connect to machine.tailnet.ts.net port 80 after 1 ms: Couldn't connect to server

steep nightBOT Apr 27, 2026, 8:39 AM

#

That curl is using HTTP on port 80. Tailscale Serve is exposing HTTPS on 443.

Use:

curl -I https://machine.tailnet.ts.net/

Not:

curl -I http://machine.tailnet.ts.net/

Also make sure you’re using the exact hostname from:

#

tailscale serve status

If HTTPS still fails, check:

tailscale status
tailscale serve status
curl -vk https://machine.tailnet.ts.net/

But the port 80 error is expected with your current Serve setup.

lethal willow Apr 27, 2026, 8:40 AM

#

curl -I https://x.y.ts.net/
HTTP/2 200
cache-control: no-cache
content-security-policy: default-src 'self'; base-uri 'none'; object-src 'none'; frame-ancestors 'none'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' ws: wss:
content-type: text/html; charset=utf-8
date: Mon, 27 Apr 2026 08:40:14 GMT
permissions-policy: camera=(), microphone=(self), geolocation=()
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: DENY

steep nightBOT Apr 27, 2026, 8:40 AM

#

Great — that means the UI is reachable over Tailscale Serve:

HTTP/2 200

So the network path is fixed.

Now open exactly:

https://x.y.ts.net/

If the browser still “can’t access” it, it’s likely not networking anymore — it’s one of:

Browser cache / service worker

#

Try private/incognito or hard refresh.

Control UI WebSocket auth/origin
Add:

gateway: {
  controlUi: {
    allowedOrigins: ["https://x.y.ts.net"],
  },
  auth: {
    allowTailscale: true,
  },
}

then restart.

#Can't spawn subagents