Gateway 2026.9.6 blocks WSL setup at guarded post-wizard restart

[shanselman]

Problem

Current Windows/WSL setup CI repeatedly finishes the Gateway wizard, restores gateway.reload.mode=hybrid, and then fails openclaw gateway restart before the health-wait loop. Shared-fixture initialization aborts and 23 setup tests fail before their test bodies run.

The exact-main passing control used Gateway 2026.9.5 (ec9c1a1). The failing runs below used Gateway 2026.9.6 (eb377ac). This establishes a version correlation and a concrete restart-contract change, but not the precise cause of every rejected owner predicate.

The ownership guard must remain fail-closed. This issue is not a request to bypass it, delete state locks, signal an unverified process, downgrade silently, or treat a retry as proof.

Reproducible CI evidence

Use the existing isolated/disposable CI environment, not a normal user workstation. The relevant suite is OpenClaw.E2ETests.Setup.SetupAndConnectTests and its shared setup fixture.

Source / run	Gateway	Observed outcome
Exact main 42c562f91a42ae0251ac971c44f6ce0f8028e88d, setup job	2026.9.5	Restart exits 0 after about 22.2 seconds, followed by HTTP 200; setup suite passes.
#1490 (fix(setup): release the setup lock only after rollback finishes), setup job	2026.9.6	Serving-owner refusal; restart exits 1 before health wait.
#1479 (fix(setup): unregister only a distro this install created), setup job	2026.9.6	Same serving-owner refusal after wizard completion.
#1480 (fix(setup): approve only the pairing request setup just opened), setup job	2026.9.6	Same serving-owner refusal after wizard completion.
#1481 (fix(setup): drop leftover gateway tokens during uninstall), setup job	2026.9.6	Same serving-owner refusal after wizard completion.
#1484 (fix(connection): open the dashboard on the tunnel, not the saved URL), setup job	2026.9.6	Distinct restart-intent write contention, described below.
#1486 (fix(setup): delete only generated uninstall children), setup job	2026.9.6	Same serving-owner refusal after wizard completion.

The two workflows containing unusually long-running Tray UI jobs were subsequently cancelled normally to bound those separate waits. Their already-completed setup failures remain the evidence above. No successful CI result is claimed for those runs, and the UI-wait cause is not established.

Keep the two failure kinds separate

Most runs report:

GatewayRestartPreparationError: GATEWAY_RESTART_PREPARATION_REFUSED:
Cannot verify a live serving Gateway owner for the selected service.
Gateway was not signaled.

The dashboard run instead positively records an approximately 5,011 ms state.write admission wait and:

StateDatabaseCoordinatorContentionError:
another OpenClaw process owns state-lifecycle

GATEWAY_RESTART_PREPARATION_REFUSED:
Cannot record restart intent for the serving Gateway.
Gateway was not signaled.

That second failure is confirmed database-coordinator contention during restart-intent recording. It does not prove that the other runs had the same cause. It also does not prove that owner verification had already passed: the state-write coordinator is acquired before the target-resolution/owner-reading callback.

Source findings

• 2026.9.5 lifecycle-core.ts, lines 501-513 performs a best-effort restart-intent write before restarting the native service.
• 2026.9.6 lifecycle-core.ts, lines 655-665 awaits mandatory preparation before service.restart.
• 2026.9.6 restart-intent.ts enforces a live supervised owner matching the selected native supervisor, or separately established stopped-service conditions, and requires intent recording.
• The default producer/consumer contract appears coherent: generated Linux service metadata supplies the expected systemd unit and service markers; the publisher detects the Linux supervisor; the consumer normalizes the same unit suffix. Default HOME/profile/state-path construction and Companion's same-distro/default-user arguments also align statically.
• Actual runtime overrides, lease state, process-start identity and the precise failed predicate are not present in the retained logs. A missing marker, wrong service, transient restart race, or identity defect has therefore not been proven.
• The fix(setup): release the setup lock only after rollback finishes #1490 window-lock change cannot execute on this failing path: the headless setup phase fails before the tray/SetupWindow phase. Its relevant headless caller-chain blobs match the passing main control. This issue should not be used to attribute the shared failure to an unrelated PR diff.

Next diagnostic boundary

Capture once before normal rollback removes the owned fixture distro, emitting only coarse allowlisted results:

• Selected unit/native runtime state and scope, unit-name equality, main-PID presence, process-start identity availability and restart-count changes.
• Config/state identity equality as booleans, not paths or contents.
• A typed owner-admission reason distinguishing unavailable owner, non-live owner, supervision mismatch, identity mismatch and coordinator contention where supported upstream.

Supported native status reads include systemctl --user show with a fixed property allowlist, ps for a validated owned PID, and openclaw gateway status --json --no-probe --timeout 5000 parsed in memory. Do not dump raw config, environment, command lines, database contents, credentials or identity files. The public status JSON does not expose the full owner lease, so it cannot by itself identify every rejected predicate.

The existing SetupPipeline.StepProgress failure event occurs before rollback and offers a diagnostic-only observer boundary. A separate harness around that pipeline would not be exact Program.Main E2E proof. Any production observer seam or upstream diagnostic change needs its own bounded review and tests.

A narrowly classified retry of the confirmed intent-recording contention may be a recovery candidate: repeat only the original guarded command within one finite total budget, never re-run the wizard/config changes, and preserve failures for other reasons. It has not been implemented or demonstrated to clear the contention, and it is not a fix for the generic owner refusals.

Expected result

A correctly identified, owned native Gateway should be restartable after setup, or should provide a precise non-secret refusal reason that permits the producer/consumer defect to be fixed. Permanent ownership mismatches must continue to fail closed. The current setup and recovery gates must pass on the intended Gateway version before claiming compatibility.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 28, 2026, 2:30 PM ET / 18:30 UTC.

Summary
The merged recovery fixes the serving-owner refusal, but restart-intent coordinator contention still blocks setup on current main. A collaborator reopened this issue for that distinct failure, and an open PR now proposes its fix.

Reproducibility: yes. Exact-main hosted setup with Gateway 2026.9.6 recorded the typed contention refusal, and the relevant restart path is unchanged at this review checkout; isolated local runs also reproduced the distinct serving-owner refusal.

Regression provenance
Possible regression — suspected (reproduction; failure trace). No predecessor PR is attributed.

Root-cause cluster
Relationship: canonical
Canonical: #1498
Summary: The open PR targets the remaining typed contention failure; the merged PR fixed a different refusal in the same post-wizard restart flow.

Members:

• fixed_by_candidate: fix(setup): retry guarded restart intent contention #1507 - Its current body explicitly targets this issue's untreated restart-intent contention.
• partial_overlap: fix(setup): retry guarded restart after reload owner handoff #1515 - It merged the serving-owner recovery but explicitly left coordinator contention untreated.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Maintainer decision needed

Question	Recommendation
Should setup accept one guarded CLI retry for the exact restart-intent coordinator-contention refusal after rechecking managed endpoint ownership?	Approve bounded guarded retry: Accept only the typed contention case after the PR fixes diagnostic disclosure and completes the required Gateway-path validation.

Why: The retry preserves the Gateway CLI guard, but its safety contract and the remaining diagnostic disclosure require explicit ownership-boundary judgment before landing the open PR.

Next step
The open linked PR already owns the remaining repair; collaborator ownership and the security-boundary decision make a second automated fix PR inappropriate.

Security
Needs attention: The proposed recovery touches Gateway restart admission, and the linked PR has an unresolved diagnostic data-disclosure finding.

Review details

Best possible solution:

Let setup recover from precisely classified transient contention through one bounded, reverified Gateway CLI retry, while preserving fail-closed admission and offering an inline recovery action with redacted diagnostics if setup still fails.

Do we have a high-confidence way to reproduce the issue?

Yes. Exact-main hosted setup with Gateway 2026.9.6 recorded the typed contention refusal, and the relevant restart path is unchanged at this review checkout; isolated local runs also reproduced the distinct serving-owner refusal.

Is this the best way to solve the issue?

Unclear until the open PR's security finding and strict-path proof are resolved. Its narrowly classified retry through the existing guarded CLI is a plausible repair.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The Gateway's rejected owner-lease predicate is not exposed, so a recovery must continue through the guarded CLI and preserve failure for persistent contention or untrusted listeners.
• The open candidate PR has an outstanding review finding about raw PID disclosure from its diagnostic probe; its reported hosted pass does not resolve that security concern.

Codex review notes: model internal, reasoning high; reviewed against 5e0b31ab830a.

Label changes

Label changes:

No label changes.

Label justifications:

• P0: Gateway 2026.9.6 can stop first-run WSL setup after the wizard, with no in-product path to complete installation.
• impact:security: Recovery must preserve the Gateway's service-owner and restart-intent admission boundary.
• impact:ux-release-blocker: A non-technical user cannot finish affected WSL setup or recover from this refusal in the product.

Evidence reviewed

Security concerns:

• [medium] Preserve guarded restart admission — src/OpenClaw.SetupEngine/SetupWizardRunner.cs:619
  A retry must repeat the Gateway CLI's owner and intent checks; endpoint provenance alone cannot authorize signaling the service.
  Confidence: 0.9
• [low] Resolve diagnostic PID disclosure
  The linked PR's current review reports that a failed proc read can place a raw PID-bearing path in uploaded setup logs.
  Confidence: 0.8

What I checked:

• Current restart behavior: Current main retries only the exact serving-owner refusal; other restart failures proceed to setup failure. (src/OpenClaw.SetupEngine/SetupWizardRunner.cs:619, 5e0b31ab830a)
• Coordinator contention remains excluded: The current regression case expects one restart attempt for the typed coordinator-contention and restart-intent refusal. (tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs:4338, 5e0b31ab830a)
• Documented boundary: Setup documentation explicitly separates restart-intent contention from serving-owner refusal and says contention is not retried. (docs/SETUP_ENGINE_REDESIGN.md:28, 5e0b31ab830a)
• Gateway CLI dependency: The Setup Engine invokes openclaw gateway restart inside WSL, so the reported refusal depends on the Gateway CLI's restart admission contract. (src/OpenClaw.SetupEngine/StartGatewayStep.cs:97, 5e0b31ab830a)
• Merged partial recovery: Commit 7d92747 added the serving-owner retry, and the relevant source and documentation have no later changes through the review checkout. (src/OpenClaw.SetupEngine/SetupWizardRunner.cs:620, 7d92747e193c)
• Exact-main failure after partial fix: The reported main-branch CI run at 7d92747 passed the serving-owner recovery lanes but failed setup/connect with typed restart-intent contention. The collaborator explicitly reopened the issue for this remaining failure: Gateway 2026.9.6 blocks WSL setup at guarded post-wizard restart #1498 (comment). (7d92747e193c)

Likely related people:

• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Scott Hanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Barbara Kudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[shanselman]

Bounded disposable-host follow-up, preserving the two original failure categories:

1. Native Linux negative control passed. On a fresh AWS Crabbox Linux VM, exact official Gateway 2026.9.6 completed one guarded systemd restart in the task-owned profile. The coarse owner/service/process-identity checks matched. No refusal or diagnostic retry occurred. Recorded run. The owned service/profile/processes and lease were cleaned up. This shows that the mandatory Linux restart path is not universally broken; it does not prove compatibility with the Windows/WSL setup sequence or identify the failed CI predicate.

2. The attempted Windows/WSL diagnostic stopped before product execution. A separate AWS WSL2 lease booted its WSL kernel and systemd, but the guest's WSLInterop registration was absent. A bounded Windows PowerShell PE invocation failed before payload transfer. Recorded readiness failure. No SetupEngine, Gateway or diagnostic distro was run or created. The complete lease was released and verified absent. This is a Crabbox guest command-route limitation, not another reproduction of the product issue.

3. Current main still reproduces the typed contention case in hosted CI. Main 0e45bb6730259bddd7a59527bd8d0dca8b4358d7, setup job, selected Gateway 2026.9.6 and reported approximately 5,011 ms waiting for state.write, followed by StateDatabaseCoordinatorContentionError: another OpenClaw process owns state-lifecycle and the restart-intent-recording refusal. The Gateway was not signaled. This is stronger than attributing the failure only to contributor branches, but still does not establish that all generic serving-owner refusals share the same cause.

No ownership bypass, lock deletion, version downgrade, speculative retry fix, or production change was made. The next useful evidence remains the rejected runtime predicate in the actual Windows/WSL setup context, captured before rollback removes the owned fixture. The retained diagnostic-only payload uses the existing --no-rollback-on-failure option for that purpose and requires explicit owned-resource cleanup; it has not been executed on a working Windows/WSL route.

[shanselman]

Additional exact-main Windows/WSL evidence after merging #1489 (fix(setup): restore gateway reload mode through stdin): at 8520c69fdf3d54849c00efb58006150a12f1fafe, setup job selected official Gateway 2026.9.6 (eb377ac). The wizard completed, then run-wizard failed at the guarded post-wizard restart before health wait with GATEWAY_RESTART_PREPARATION_REFUSED: Cannot verify a live serving Gateway owner for the selected service. Gateway was not signaled. The setup suite finished 17 passed, 23 failed, 6 skipped; the adjacent Tray/setup/integration job succeeded. This is the generic serving-owner refusal on exact main, distinct from the previously observed typed state.write contention on exact main 0e45bb67. Both failure categories now occur on adjacent main trees; do not infer one cause or attribute this shared Gateway 2026.9.6 fixture failure to a contributor patch. The ownership guard remains fail-closed. A bounded diagnostic lane is collecting only allowlisted owner/service status before rollback.

[shanselman]

Bounded diagnostic follow-up from PR #1507 (test(setup): capture guarded restart state before fixture rollback), CI run 35993290413 on official Gateway 2026.9.6. The three independent E2E fixtures all failed at the guarded post-wizard restart; no retry or ownership bypass was attempted.

CI job	Coarse refusal category	Selected service snapshot before rollback
Setup/connect 107612506610	coordinator_contention (typed StateDatabaseCoordinatorContentionError)	probe=ok, scope=user, unitEqual=true, active=active, sub=running, pidPresent=true, pidLive=true, pidEqual=true, processStartAvailable=true, serviceStartAvailable=true, restartCount=1
Revocation 107612506607	serving_owner_unverified (generic refusal, no typed contention observed)	Same 11 coarse fields and values.
Network 107612506669	serving_owner_unverified (generic refusal, no typed contention observed)	Same 11 coarse fields and values.

For all jobs, ownerPredicate=not_exposed_by_gateway_cli. pidEqual compares systemd MainPID with ExecMainPID, not Gateway's owner lease. A live unit/PID at the later observer point does not prove the lease matched when restart admission ran, nor that the two refusal categories share a cause. Each setup journal recorded pipeline_failed=1 and rollback_ok=19; each subsequent uninstall journal recorded rollback_ok=34 and uninstall_completed=1. No fixture was intentionally preserved. Only validated allowlisted diagnostic fields and cleanup event counts are reported; existing raw CI artifact contents are not linked or reproduced.

The precise rejected owner predicate remains blocked on upstream Gateway exposing a typed, redacted reason or a disposable-host instrumented repro. The CI gate remains red, and the diagnostic PR must not be merged as a compatibility fix.