Setup failing after cli is installed

[jeffmaury]

Setup is failing: once the WSL distribution is setup, following commands are failing, seems because %LOCALAPPDATA%\temp is not accessible

setup-engine-20260916-165555.txt

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 16, 2026, 1:16 PM ET / 17:16 UTC.

Summary
Keep open: the attached log establishes an onboarding failure after successful CLI installation. Current main retains the failing launch path, and no verified fix or canonical replacement was found.

Reproducibility: no. high-confidence current-main reproduction is established. The reporter's log proves a real Windows launch failure, but the affected Companion build and conditions distinguishing failed configuration launches from successful adjacent launches are unknown.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Prioritize Windows setup investigation: identify the Companion build and capture sanitized native launch diagnostics to distinguish executable resolution, working-directory access and host enforcement before choosing a repair.

Review details

Best possible solution:

Restore reliable gateway configuration through the existing setup engine and provide an inline Doctor or Retry recovery path for launch failures without requiring manual permission changes.

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

No high-confidence current-main reproduction is established. The reporter's log proves a real Windows launch failure, but the affected Companion build and conditions distinguishing failed configuration launches from successful adjacent launches are unknown.

Is this the best way to solve the issue?

Unclear: the failure is localized to Windows process startup, but source inspection does not justify a specific permission, working-directory or WSL-launch fix yet.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The Companion build and Windows native denial cause remain unknown; changing Temp permissions or executable resolution without isolating the failure could address the wrong mechanism.

Codex review notes: model internal, reasoning medium; reviewed against 3c43751b2bac.

Label changes

Label changes:

• add P0: Local onboarding fails after three configuration attempts and rolls back the installation, with no demonstrated in-product path to completion.
• add impact:ux-release-blocker: The supplied setup log shows a first-run gateway setup blocker currently requiring technical investigation.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P0: Local onboarding fails after three configuration attempts and rolls back the installation, with no demonstrated in-product path to completion.
• impact:ux-release-blocker: The supplied setup log shows a first-run gateway setup blocker currently requiring technical investigation.

Evidence reviewed

What I checked:

• Reporter log confirms a process-start failure: Read the attached 125-line JSONL log at https://github.com/user-attachments/files/32300085/setup-engine-20260916-165555.txt. Captured SHA-256: dc07a54c725fa218f79c6883c1232f88de1a1299ce17d437d38b3329a1185095. Lines 77–82 report successful CLI installation, Gateway 2026.9.4 and Node v24.19.0. Lines 90–102 record three Windows process-start failures with access denied, followed by rollback. Bare wsl.exe launches succeed immediately before configuration and again during rollback, so permanent Temp-directory inaccessibility is not established.
• Current configuration entrypoint: ConfigureGatewayStep supplies the gateway-token environment and invokes RunInWslAsync; a nonzero result becomes a setup failure. The reported failure occurs before the configuration script starts, rather than inside a Gateway config command. (src/OpenClaw.SetupEngine/ConfigureGatewayStep.cs:92, 3c43751b2bac)
• Windows launch boundary remains present: RunInWslAsync launches bare wsl.exe without an explicit working directory. RunAsyncCore inherits the working directory, applies environment overrides, and converts a Process.Start Win32Exception into exit -1 with the message seen in the log. This locates the failure boundary but does not establish which Windows condition denied the launch. (src/OpenClaw.SetupEngine/CommandRunner.cs:209, 3c43751b2bac)
• Existing tests do not resolve this launch failure: CommandRunnerTests covers WSL output decoding, stdin, cancellation and output draining. Configuration tests use FakeCommandRunner for successful configuration and timeout handling; these do not reproduce the reporter's Windows access-denied launch. (tests/OpenClaw.SetupEngine.Tests/CommandRunnerTests.cs:11, 3c43751b2bac)
• Current main and release identity: The checkout is the supplied current-main SHA and carries tag v2026.9.4. GitHub's latest release is v2026.9.4, published 2026-09-15. No fix for this launch failure was established in either. The log identifies the installed Gateway version, but does not identify the Companion build. (3c43751b2bac)
• Related work does not own this failure: The open-PR listing revealed no explicit fix for this process-start failure. fix(setup): keep legacy fallback on exact stable release #1412 (fix(setup): keep legacy fallback on exact stable release) changes version selection. The merged Fix onboarding wizard Back desynchronization #1205 (Fix onboarding wizard Back desynchronization) addresses wizard navigation and closes a different issue; its complete body does not connect it to this failure.

Likely related people:

• shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• RomneyDa: 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.