Problem

When gateway.bind is set to lan (or any non-loopback address), sessions_spawn sub-agents receive the LAN IP as their gateway URL (e.g. ws://192.168.86.25:18789).

The security hardening in v2026.2.21 correctly rejects plaintext ws:// to non-loopback addresses:

SECURITY ERROR: Gateway URL "ws://192.168.86.25:18789" uses plaintext ws://
to a non-loopback address. Both credentials and chat data would be exposed
to network interception.

This completely breaks sub-agent spawning for anyone running the gateway bound to a LAN or Tailscale IP — which is a common setup for multi-device households.

Expected Behavior

Sub-agents running on the same host as the gateway should connect via loopback (ws://127.0.0.1:<port>), not via the external bind address. The security check would pass, no TLS required, no new auth needed.

Proposed Fix

Add a gateway.internalUrl config option (default: auto-derive as ws://127.0.0.1:<port>) that sessions_spawn uses when spawning sub-agents on the same host. The external bind address continues to be used for phones/external clients.

{
  "gateway": {
    "bind": "lan",
    "internalUrl": "ws://127.0.0.1:18789"
  }
}

Alternatively, auto-detect same-host sub-agents and always route them to loopback without requiring explicit config.

Workaround

None viable without either:

• Logging Claude Code into an additional device (hits OAuth device limits)
• Setting up TLS/Tailscale Serve (significant complexity for a local-only concern)
• Changing bind to loopback and routing all external traffic through a reverse proxy

Impact

This breaks the core local sub-agent workflow for any multi-device gateway setup. Given sub-agents are central to the coding agent use case, this is a significant regression from v2026.2.19.