sessions_spawn pairing required issue

[smoky valley]

Hey everyone — running into the sessions_spawn pairing required issue on 2026.4.12 (Linux/Hetzner VPS)
Setup: OpenClaw 2026.4.12, Ubuntu, systemd user service, gateway bind=loopback, auth mode=token, WhatsApp channel.
The issue: sessions_spawn fails with gateway closed (1008): pairing required every single time, regardless of how it's triggered:

Agent calling sessions_spawn tool → pairing required
User sending /subagents spawn from WhatsApp → pairing required
Both return: Source: local loopback in the error

What I've already tried:

Added trustedProxies: ["127.0.0.1"] to gateway config
Ran openclaw doctor --fix
Cleared paired devices
Upgraded from earlier versions (was hoping 2026.4.2 fix PR #59555 would resolve it)
Multiple gateway restarts

Config is correct: agents_list works fine, allowAgents: ["extractor"] is set, maxSpawnDepth: 2 is configured, extractor agent directory exists with auth-profiles.json copied from main. Everything looks right but spawning always fails.
From my research: I found GitHub issues #59428, #23160, #23642, #22353 all reporting the same thing across versions going back to 2026.2.x. PR #59555 in 2026.4.2 was supposed to fix it but clearly hasn't for everyone. I also noticed the Discord message about Telegram allowlist mode triggering the same scope-upgrade pairing error — seems like the same root cause.
Questions:

Has anyone on 2026.4.12 actually gotten sessions_spawn working on a loopback Linux setup?
Is there a specific config combination that makes it work?
Is there a known timeline for a proper fix?

Currently working around it by running scripts manually from terminal and having Edward read the output files, but autonomous subagent delegation is the goal. Any help appreciated

So that's what I've found trying to configure everything using Claude Sonnet, research and everything and this is a little summary of what happend so far. I'm definitely not an expert but wanted to know if it was true and this is an issue that needs fixing.

[dreamy shell]

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

[strange trail]

I checked current docs/source, and your summary is basically right: this looks like a real pairing/scope-upgrade issue, not bad allowAgents / maxSpawnDepth config.

A few concrete points:

• Source: local loopback + 1008 pairing required points to device pairing / scope upgrade, not subagent config.
• gateway.trustedProxies: ["127.0.0.1"] is not the fix here. Docs say loopback entries only help forwarded-IP handling, they do not make same-host loopback requests eligible for trusted-proxy auth.
• #59555 fixed one sessions_spawn scope-mix case, but current source still has backend reconnect paths where a scope upgrade can end in pairing required. So yes, this can still reproduce on 2026.4.12.

What I’d try next, immediately after reproducing:

pnpm openclaw devices list
pnpm openclaw devices approve <requestId>

If the pending request shows operator.write or operator.admin, that’s the smoking gun. sessions_spawn is a write/admin path, so if the local backend device was previously paired at a lower scope, spawn triggers a new pairing request and the headless connection drops.