Summary

One-sentence statement of what is broken:
Subagent sessions cannot connect to the gateway due to a "pairing required" error,
preventing the creation of execution-layer subagents that would use cheaper default models.

Steps to reproduce

Provide the shortest deterministic repro path:

1. Configure gateway with
   auth.mode: "token" and
   bind: "loopback"
2. Start the gateway service:
   openclaw gateway start
3. From a main session, attempt to create a subagent using the
   task: "Execute this task"
   label: "executor"
   mode: "run"
   sessions_spawn tool:
   model: "cherry-nvidia/qwen/qwen3-235b-a22b" (default model)
4. Observe the error:
   gateway closed (1008): pairing required

Expected behavior

Provide the shortest deterministic repro path:

1. Configure gateway with
   auth.mode: "token" and
   bind: "loopback"
2. Start the gateway service:
   openclaw gateway start
3. From a main session, attempt to create a subagent using the
   task: "Execute this task"
   label: "executor"
   mode: "run"
   sessions_spawn tool:
   model: "cherry-nvidia/qwen/qwen3-235b-a22b" (default model)
4. Observe the error:
   gateway closed (1008): pairing required

Actual behavior

Actual behavior *
What happened instead, including user-visible errors:
Subagent sessions fail to connect with a pairing error. The gateway rejects the connection
because it requires a scope upgrade:

OpenClaw version

2026.2.21 (d9844c6)

Operating system

Linux 6.17.0-14-generic (x64)

Install method

npm global (via openclaw CLI)

Logs, screenshots, and evidence

Include	redacted	logs/screenshots/recordings	that	prove	behavior:
Gateway	Log	Output
{"subsystem":"gateway"}	security	audit:	device	access	upgrade	requested	reason=scope-upgrade	device=7f416
gateway	connect	failed:	Error:	pairing	required
{"subsystem":"gateway/ws"}	closed	before	connect	conn=30d293e4-2aff-4167-a735-a728653f8e



Subagent	Creation	Error
{
}

Impact and severity

Explain who is affected, how severe it is, how often it happens, and the practical
consequence:
Affected: Users attempting to use subagent sessions for cost optimization (brain layer +
execution layer)
Severity: High - Blocks a core cost-saving architecture
Frequency: 100% reproducible when creating subagent sessions
Consequences:
Cannot separate planning (advanced model) from execution (default model)
Both planning and execution must use the same expensive advanced model
Significantly increases API costs
Limits usefulness of subagents for local development
This prevents a key architectural pattern that would save substantial API costs by using
cheaper models for execution tasks.

Additional information

Add any context that helps triage but does not fit above:
Root Cause
The subagent session attempts to connect to the gateway and requests a scope upgrade:
From:
operator (scopes: admin, approvals, pairing, read)
To:
operator.write (adds write capability)
The gateway rejects this with "pairing required", but:

1. This is an internal connection (loopback), not an external node
2. The pairing request does NOT appear in
   openclaw nodes pending
3. No configuration option exists to auto-approve internal scope upgrades
   Workarounds Tested
4. Change
   auth.mode to
   "off"
   Attempted: Modified
   gateway.auth.mode to
   Result: Configuration error -
5. Use
   openclaw nodes approve
   "off"
   "off" is not a valid option in the schema
   Attempted: Checked
   openclaw nodes pending
   Result: "No pending pairing requests" - the request is not in the nodes system
6. Simulate two-layer architecture in single session
   Problem: Cannot switch models within a single session - both planning and execution
   would use the same expensive model
   Suggested Solutions
   Option 1: Auto-approve Internal Scope Upgrades
   For loopback gateway connections (
   bind: "loopback" ), automatically approve scope
   upgrades from
   operator to
   operator.write when the client is
   gateway-client (internal).
   Rationale:
   Loopback connections are trusted (same machine)
   gateway-client is an internal client, not an external node
   This is an internal gateway mechanism, not external node pairing