**Sub-agent spawn fails: "device token mismatch" — gateway injects stale token into sub-agent proces
OpenClaw v2026.2.15, Hetzner VPS, Ubuntu 24.04 ARM, sandbox mode (Docker, bridge networking, read-only rootfs).
Sub-agents worked perfectly on v2026.2.9 (Feb 11-13). Broke between Feb 13-16 during security hardening + gateway update to v2026.2.15.
Error: gateway closed (1008): unauthorized: device token mismatch
Root cause: Sub-agent runs in the same container (no new container created). Process gets HOME=/root, looks for config at /root/.openclaw/ which doesn't exist on read-only rootfs. But the real issue is the gateway injects a device token directly into the sub-agent process that doesn't match any paired device.
What we proved:
OPENCLAW_HOME/STATE_DIR/CONFIG_PATH env vars DO influence the sub-agent (connection URL changed from LAN IP to loopback) — but token mismatch persists
docker.binds accepted by schema but NOT applied to container at runtime
Disabling gateway auth (mode: none) — no difference
Revoked all stale devices, single paired device remains — still fails
No version mismatch: CLI and gateway both confirmed v2026.2.15
Tried: token rotation, device revoke/re-pair, container nuke (x5), setupCommand, readOnlyRoot:false, bind mounts, env var overrides — 12 fix attempts total
Config: agents.defaults.sandbox: mode all, scope agent, docker bridge, user 1000:1000, custom image. Single paired device on 172.17.0.2.
Ask: How does the gateway provision the device token for sub-agent processes? Is there a way to control it? Is this a known regression in v2026.2.15?
Sub-agents worked perfectly on v2026.2.9 (Feb 11-13). Broke between Feb 13-16 during security hardening + gateway update to v2026.2.15.
Error: gateway closed (1008): unauthorized: device token mismatch
Root cause: Sub-agent runs in the same container (no new container created). Process gets HOME=/root, looks for config at /root/.openclaw/ which doesn't exist on read-only rootfs. But the real issue is the gateway injects a device token directly into the sub-agent process that doesn't match any paired device.
What we proved:
OPENCLAW_HOME/STATE_DIR/CONFIG_PATH env vars DO influence the sub-agent (connection URL changed from LAN IP to loopback) — but token mismatch persists
docker.binds accepted by schema but NOT applied to container at runtime
Disabling gateway auth (mode: none) — no difference
Revoked all stale devices, single paired device remains — still fails
No version mismatch: CLI and gateway both confirmed v2026.2.15
Tried: token rotation, device revoke/re-pair, container nuke (x5), setupCommand, readOnlyRoot:false, bind mounts, env var overrides — 12 fix attempts total
Config: agents.defaults.sandbox: mode all, scope agent, docker bridge, user 1000:1000, custom image. Single paired device on 172.17.0.2.
Ask: How does the gateway provision the device token for sub-agent processes? Is there a way to control it? Is this a known regression in v2026.2.15?
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
130,529Members
Resources
Similar Threads
Was this page helpful?
