Skip to content

sessions_spawn fails with pairing required on local loopback with token auth #63548

@yuren19810323-pixel

Description

@yuren19810323-pixel

Issue: sessions_spawn fails with "pairing required" on local loopback with token auth

Environment

  • OpenClaw version: 2026.4.8 (upgraded from 2026.4.2)
  • OS: Windows 10 (10.0.26200, x64)
  • Node: v24.14.1
  • Gateway config: bind: loopback, auth.mode: token
  • Channel: Feishu (direct chat)

Description

When calling sessions_spawn with runtime: "subagent" from an agent session, the spawned subagent fails to connect back to the gateway WebSocket with error:

gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: local loopback

This occurs despite:

  1. Gateway running on loopback only (bind: loopback)
  2. Token auth configured (gateway.auth.mode: "token")
  3. The subagent inherits the gateway token from openclaw.json
  4. Agent session is fully operational (can use all other tools, exec, web_search, etc.)

Root Cause Analysis

I traced through the source code and found the issue:

Connection Flow

The subagent connects via WebSocket with:

  • client.id: cli (from GATEWAY_CLIENT_IDS.CLI)
  • client.mode: cli (from GATEWAY_CLIENT_MODES.CLI)
  • role: "operator" (from call-BjnDacVz.js:425)

Auth Check Path

  1. evaluateMissingDeviceIdentity() in server.impl-WjqjRArz.js (~line 27570):

    • roleCanSkipDeviceIdentity("operator", sharedAuthOk) should return { kind: "allow" } when sharedAuthOk === true
  2. shouldSkipLocalBackendSelfPairing() (~line 27641):

    • Requires client.mode === "backend", but subagent connects with mode: "cli"
    • This path is never taken for subagent connections
  3. roleCanSkipDeviceIdentity() (~line 10387):

    • Returns true when role === "operator" && sharedAuthOk
    • This should work, but the subagent still gets rejected

Key Observation

The devices/ directory (~/.openclaw/credentials/devices/) is empty — no paired devices exist. The subagent generates a new device identity each time (resolveDeviceIdentityForGatewayCall()loadOrCreateDeviceIdentity()), which has no matching paired device record.

It appears that sharedAuthOk may not be resolving to true for the subagent's connection, or the device identity check is happening before the shared auth check.

Relevant Code Locations

  • call-BjnDacVz.js:420-425 — subagent connects as mode: CLI, role: "operator"
  • server.impl-WjqjRArz.js:27433sharedAuthOk resolution
  • server.impl-WjqjRArz.js:27560-27575evaluateMissingDeviceIdentity()
  • server.impl-WjqjRArz.js:27641-27649shouldSkipLocalBackendSelfPairing()
  • server.impl-WjqjRArz.js:10387-10388roleCanSkipDeviceIdentity()
  • server.impl-WjqjRArz.js:28282 — final close(1008, "pairing required")

Expected Behavior

Subagent spawned by sessions_spawn on a local loopback gateway with token auth should be able to connect without requiring device pairing, since:

  1. The connection is local (loopback)
  2. Token auth is valid
  3. The role is "operator"

Workaround

Using exec to call claude --print --permission-mode bypassPermissions directly works fine for coding tasks, completely bypassing the subagent WebSocket connection.

Reproduction

  1. Set up OpenClaw on Windows with gateway.bind: loopback, gateway.auth.mode: token
  2. Have a Feishu channel configured and working
  3. From agent session, call sessions_spawn with runtime: "subagent" and any task
  4. Observe: "gateway closed (1008): pairing required"

Suggested Fix

Either:

  • Ensure sharedAuthOk resolves correctly for subagent connections on local loopback with token auth
  • Or add a skip path for locally-spawned subagents similar to shouldSkipLocalBackendSelfPairing but for CLI-mode connections
  • Or allow roleCanSkipDeviceIdentity to work regardless of device identity when auth is valid on loopback

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions