fix: local gateway connections recover after listener or token drift#1053
Draft
bkudiess wants to merge 2 commits into
Draft
fix: local gateway connections recover after listener or token drift#1053bkudiess wants to merge 2 commits into
bkudiess wants to merge 2 commits into
Conversation
Add trusted endpoint provenance, role-aware credential recovery, explicit operator intent, and bounded managed-WSL repair so local gateway failures recover safely without leaking stronger credentials or overriding disconnects. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
clawsweeper
Bot
added
rating: 🦪 silver shellfish
|
Codex review: needs maintainer review before merge. Reviewed July 24, 2026, 4:35 PM ET / 20:35 UTC. ClawSweeper reviewWhat this changesThis PR adds verified local-listener ownership checks, role-specific device-token recovery, and bounded automatic WSL gateway repair for setup-managed local connections. Merge readiness⛔ Blocked until stronger real behavior proof is added - 5 items remain Keep this draft open for human review. It introduces a large, security-sensitive local-gateway recovery path, and the supplied evidence does not independently demonstrate the exact-head non-isolated repair flow or its upgrade behavior. Priority: P2 Review scores
Verification
How this fits togetherThe tray connects operator and Windows-node clients to configured gateways using records and credentials stored locally. This patch inserts listener-provenance checks before credential use and reconnects, then uses bounded WSL repair and connection UI recovery states when a setup-managed local gateway fails. flowchart LR
A[Gateway record and credentials] --> B[Connection manager]
B --> C[Local listener provenance check]
C --> D{Verified managed WSL gateway?}
D -->|Yes| E[Reconnect or bounded WSL repair]
D -->|No| F[Local port conflict]
E --> G[Operator and node connection state]
F --> G
G --> H[Connection recovery UI]
Decision needed
Why: The patch creates a new autonomous recovery capability that can restart a WSL distro and stop a process after provenance checks; code review alone cannot determine whether that operational and security boundary matches maintainer policy. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Keep a narrowly scoped, fail-closed provenance boundary, then provide redacted current-head fault-injection evidence plus explicit fresh-install and upgrade coverage before deciding whether to accept automatic WSL repair as a default behavior. Do we have a high-confidence way to reproduce the issue? No high-confidence independent reproduction was completed in this review. The source and PR body define a concrete Windows plus WSL fault-injection path, but the supplied current-head proof is summary-only and the reported non-isolated run was blocked. Is this the best way to solve the issue? Unclear. The design attempts to centralize lifecycle and provenance safely, but its default-on autonomous restart and remediation policy needs maintainer approval and exact-head upgrade proof before it can be called the best solution. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against f50af187865c. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
Preserve WSL shell variables through stdin, isolate the Windows PowerShell module path for Authenticode verification, and account for relay family translation. Update the keepalive E2E contract to recognize an already-proven setup keepalive without spawning a duplicate. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: fix: local gateway connections recover after listener or token drift This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Problem This Solves
Fixes an issue where users connected to a setup-managed local WSL gateway could
be left in misleading re-pair/token states or unstable reconnect loops when a
stale native gateway owned the local port, the WSL gateway was wedged, or a
role-specific device token drifted.
Why This Change Was Made
This makes
GatewayConnectionManagerthe canonical operator/node lifecycle anduser-intent owner, adds a shared local-listener provenance service, and adds a
bounded managed-WSL repair monitor/coordinator. Strong shared/bootstrap
credentials are sent only after the expected local gateway owner is proven;
unknown listeners are never killed, and explicit Disconnect/Stop intent is
never overridden by automatic repair.
The old owners were scattered UI/client reconnect paths and best-effort port
diagnostics. The new owners are the connection manager for lifecycle and
credential recovery,
ManagedLocalGatewayPortProvenanceServicefor endpointidentity/remediation, and the monitor/coordinator for bounded automatic repair.
User Impact
Setup-managed local gateways now recover automatically from stale listener
collisions, WSL service/VM failures, and role-specific device-token mismatch.
When ownership cannot be proven, the UI reports a local port conflict instead
of incorrectly asking the user to re-pair.
Evidence
OpenClaw native listener, left the task disabled, restored signed
wslrelay.exeownership in about 50 seconds, returned the WSL systemd gatewayto
active, and refreshedLastConnected.relay without terminating an unknown process.
127.0.0.1:18789is owned byC:\Program Files\WSL\wslrelay.exe(PID 38548);OpenClawGatewayisactive/running(MainPID 483).9d418433launched successfully in isolated mode and remainedresponsive as PID 41088.
c2e13727completed the real fresh-distro setup/connect,revocation-recovery, and network-recovery E2E shards. This also proved signed
wslrelayverification under a PowerShell 7 parent and dual-stack Windowsrelay projection onto the expected systemd-owned WSL socket.
Claude Opus 4.8 95/100, Gemini 3.1 Pro 100/100; no material findings.
material blockers and confirmed model-catalog, settings, exec-approval, and
connection-recovery behavior remain wired.
Change Type
Scope
winnodeValidation
.\build.ps1dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --no-restoredotnet test .\tests\OpenClaw.Connection.Tests\OpenClaw.Connection.Tests.csproj --no-restoredotnet test .\tests\OpenClaw.SetupEngine.Tests\OpenClaw.SetupEngine.Tests.csproj --no-restoredotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restoreKnown telemetry listener tests flaked transiently during exploratory runs.
Their isolated reruns passed, and the complete required closeout rerun passed.
Real Behavior Proof
OpenClawGateway, setup-managedloopback gateway on port 18789.
c2e13727..\run-app-local.ps1 -NoBuild -AllowNonMain -Isolated; inspected theaddress-specific Windows listener and WSL systemd service; repeated controlled
native-listener collision/recovery trials before the mechanical rebase; ran
all three CI setup E2E filters on the current head.
relay owns the loopback listener; WSL service is active/running; controlled
collisions self-repaired without sending strong credentials to or killing an
unproven owner; current-head fresh-distro setup, revocation, network recovery,
and keepalive idempotence all passed.
user intent and unknown-listener safety remain authoritative.
Yes/No/N/A): N/A; copiedterminal/runtime evidence is included above.
global singleton already owned by another worktree (PID 2496), which was not
terminated. Current-head runtime behavior was instead exercised through the
real fresh-distro E2E shards; non-isolated collision recovery was exercised
repeatedly on the identical feature snapshot before the conflict-free rebase.
Security Impact
Yes/No): No.Yes/No): Yes.Yes/No): Yes, local listener/provenance andreconnect probes only.
Yes/No): Yes, bounded repaircan restart the expected WSL service/VM and disable/stop only a fully proven
obsolete OpenClaw native task/process.
Yes/No): No.Yes, explain the risk and mitigation: shared/bootstrapcredentials are now gated by complete Windows IPv4/IPv6 listener capture,
signed relay, expected-distro systemd MainPID target-port ownership, and
listener recapture. Destructive remediation additionally proves native
task/profile/process lineage and PID start identity. Unknown owners fail closed.
Compatibility and Migration
Yes/No): Yes.Yes/No): No.Yes/No): Yes, automatic only.Dev, direct-override, and legacy
Local (<distro>)records are migrated orresolved in place.
Review Conversations