fix(onboard): gate Windows-host Ollama on Docker Desktop WSL

[zyang-dev]

Summary

This PR keeps Windows-host Ollama options visible during WSL onboarding, but clearly marks them as requiring Docker Desktop WSL integration when native Docker Engine is detected. Selecting those providers in an unsupported native Docker-in-WSL topology now fails early with an actionable message instead of continuing into a confusing install failure.

Related Issue

Fixes #4208, Fixes #4421, Fixes #4257

Changes

• Detect whether Windows-host Ollama provider paths are supported for the current WSL Docker topology.
• Label Windows-host Ollama menu entries as requiring Docker Desktop WSL integration when native Docker Engine is detected.
• Block start-windows-ollama and install-windows-ollama before launching or installing Ollama in unsupported native Docker-in-WSL setups.
• Move Ollama menu label helpers out of onboard.ts.
• Add focused onboarding selection tests for the native Docker-in-WSL guardrail.

Type of Change

• Code change (feature, bug fix, or refactor)
• Code change with doc updates
• Doc only (prose changes, no code sample modifications)
• Doc only (includes code sample changes)

Verification

• npx prek run --all-files passes
• npm test passes
• Tests added or updated for new or changed behavior
• No secrets, API keys, or credentials committed
• Docs updated for user-facing behavior changes
• npm run docs builds without warnings (doc changes only)
• Doc pages follow the style guide (doc changes only)
• New doc pages include SPDX header and frontmatter (new pages only)

---

Signed-off-by: zyang-dev 267119621+zyang-dev@users.noreply.github.com

Summary by CodeRabbit

• New Features

  • Better detection and menu entry for running local Ollama instances with clearer host/WSL labels and suggested routing.
  • New requirement-driven labels and gating for Windows-host Ollama start/install options.

• Bug Fixes

  • Early rejection and clearer messaging for unsupported Windows Docker/WSL setups, including non-interactive abort behavior.
  • Port validation now respects non-interactive flows and warns/aborts appropriately.

• Tests

  • Added and extended tests for Windows-host routing, non-interactive aborts, and suggested-label scenarios.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: d8151eb3-2ab9-4675-aab2-f2e2a7fe4d91

📥 Commits

Reviewing files that changed from the base of the PR and between c55b6fd and 7fdbb5d.

📒 Files selected for processing (2)

• src/lib/onboard.ts
• test/onboard-selection.test.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• test/onboard-selection.test.ts

---

📝 Walkthrough

Walkthrough

Computes a Windows-host Ollama Docker requirement from container runtime, adds host-aware running-Ollama menu entry and port validation, renames the provider fallback flag to canUseWindowsHostOllama, integrates requirement-driven labels and early rejection into onboarding, and updates tests to mock topology/runtime for WSL/Docker scenarios.

Changes

Windows-host Ollama Docker Requirement Gating

Layer / File(s)	Summary
Windows-host Ollama Docker requirement model src/lib/onboard/local-inference-topology.ts	Added WindowsHostOllamaDockerRequirement discriminated union, describeContainerRuntime, getWindowsHostOllamaDockerRequirement(runtime) and rejectUnsupportedWindowsHostOllama(...) to represent support/unsupported cases and provide non-interactive abort handling.
Running Ollama menu entry & port checks src/lib/onboard/ollama-install-menu.ts, src/lib/onboard/ollama-install-menu.test.ts	Added RunningOllamaMenuInput, resolveRunningOllamaMenuEntry() to produce host-aware ollama menu entries (Windows host / WSL / localhost variants with running/suggested suffixes) and checkOllamaPortsOrWarn() to validate port configuration and handle non-interactive failure. Included unit test for running-entry label under WSL.
Provider-key fallback rename and tests src/lib/onboard/provider-key-fallback.ts, src/lib/onboard/provider-key-fallback.test.ts	Renamed context flag isWindowsHostOllama → canUseWindowsHostOllama, updated fallback resolution logic for start-windows-ollama / install-windows-ollama, and updated tests to use the new option name.
Onboarding provider selection integration src/lib/onboard.ts	Compute windowsHostOllamaDockerRequirement, use resolveRunningOllamaMenuEntry to conditionally add a running-Ollama option, replace hardcoded Windows-host labels with requirement-driven startLabel/installLabel, add rejectWindowsHostOllama(...) wrapper to call rejectUnsupportedWindowsHostOllama(...), and pass { isNonInteractive } into port checks.
Integration & regression tests (topology mocking) test/onboard-selection.test.ts	Updated generated onboarding scripts to import topology, mock topology.getContainerRuntime() (e.g., docker-desktop / docker), standardize local.getOllamaModelOptions stubs, and add integration and non-interactive regression tests verifying Docker Desktop WSL labeling and abort behavior.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• NVIDIA/NemoClaw#4219: Related non-interactive abort/abortNonInteractive changes that touch onboarding failure handling.
• NVIDIA/NemoClaw#4212: Modifies Ollama startup gating in onboarding; overlaps with provider handling for ollama.
• NVIDIA/NemoClaw#3969: Changes Windows-host Ollama detection and routing logic relevant to this area.

Suggested labels

Docker, fix, Provider: Ollama

Suggested reviewers

• ericksoa
• cv
• jyaunches

Poem

🐰 I hopped through ports and WSL night,
Mapped runtimes, labels, and docker light.
When Desktop's missing, I softly say "No" —
Abort for non-interactive, so flows stay slow.
A tiny menu, a rabbit's guide, now clearer to show.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'fix(onboard): gate Windows-host Ollama on Docker Desktop WSL' directly summarizes the main change—adding gating logic to restrict Windows-host Ollama support based on Docker Desktop WSL availability.
Linked Issues check	✅ Passed	Changes implement gating of Windows-host Ollama on Docker Desktop WSL (#4208, #4421) via new requirement modeling, early rejection of unsupported configurations, and updated menu helpers—addressing both the non-interactive exit-code-1 issue and the auth-proxy reachability problem.
Out of Scope Changes check	✅ Passed	All changes—local-inference-topology.ts, ollama-install-menu.ts, provider-key-fallback.ts, onboard.ts, and test files—are directly in scope for implementing the Docker Desktop WSL gating requirement and related onboarding safeguards.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/windows-ollama-docker-desktop-requirement

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint skipped: no ESLint configuration detected in root package.json. To enable, add eslint to devDependencies.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

E2E Advisor Recommendation

Required E2E: gpu-e2e, wsl-repo-cloud-openclaw
Optional E2E: gpu-double-onboard-e2e, onboard-negative-paths-e2e, onboard-inference-smoke-e2e

Dispatch hint: gpu-e2e

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• gpu-e2e (high): Runs the real Local Ollama onboarding flow with NEMOCLAW_PROVIDER=ollama: installs Ollama, lets onboard start it, configures the auth proxy/inference route, creates the sandbox, and proves sandbox inference. This directly covers the changed Ollama menu/selection and local-inference topology paths on a real runtime.
• wsl-repo-cloud-openclaw (medium): Runs the scenario-based WSL onboarding/sandbox smoke path on windows-latest. The PR is specifically about WSL runtime detection and Windows-host Ollama gating, so a real WSL environment should be merge-blocking even though the existing scenario uses cloud inference.

Optional E2E

• gpu-double-onboard-e2e (high): Useful adjacent coverage for Ollama re-onboard and auth-proxy token consistency after the provider-selection/topology changes, but the primary changed path is initial selection/gating rather than re-onboard token persistence.
• onboard-negative-paths-e2e (medium): Provides broad non-interactive onboarding failure-mode coverage for provider/model/env handling. It does not currently exercise Windows-host Ollama, so it is a useful sanity check but not the most targeted E2E for this PR.
• onboard-inference-smoke-e2e (low): Checks that configured inference routes are proven with a real smoke probe before reporting success. This is adjacent to provider selection and route setup but does not target WSL/Windows-host Ollama directly.

New E2E recommendations

• wsl-windows-host-ollama-boundary (high): Existing WSL E2E coverage on windows-latest uses cloud inference, while existing local Ollama E2E coverage runs on Linux GPU. There is no existing E2E that starts or rejects Windows-host Ollama from WSL under Docker Desktop vs native Docker-in-WSL, which is the core behavior changed here.
  • Suggested test: Add a WSL scenario or workflow job that runs onboarding with NEMOCLAW_PROVIDER=start-windows-ollama/install-windows-ollama in WSL, covering both Docker Desktop-supported routing to host.docker.internal and the native Docker-in-WSL fail-closed rejection.

Dispatch hint

• Workflow: nightly-e2e.yaml
• jobs input: gpu-e2e

[github-actions]

E2E Scenario Advisor Recommendation

Required scenario E2E: None
Optional scenario E2E: None

Workflow run

Full scenario advisor summary

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• None. No scenario workflow, scenario metadata, scenario runtime, or validation-suite files changed.

Optional scenario E2E

• None.

Relevant changed files

• None.

[github-actions]

PR Review Advisor

Findings: 1 needs attention, 3 worth checking, 0 nice ideas
Since last review: 0 prior items resolved, 3 still apply, 0 new items found

Review findings

🛠️ Needs attention

• PR links fixes for Windows-host Ollama completion issues but implements an unsupported-topology gate (src/lib/onboard/local-inference-topology.ts:67): The PR body says it fixes [WSL2][Onboard] install exits 1 after start-windows-ollama / install-windows-ollama provider handoff succeeds #4208, [NemoClaw][Onboard][Windows] nemoclaw onboard stops after step [4/8]; no sandbox created even though Ollama is responsive #4257, and [WSL2 x86_64][Inference] Onboard with 'Start Ollama on Windows host' fails at [4/8] — auth proxy at host.openshell.internal:11435 not started #4421. The most direct linked acceptance in [WSL2 x86_64][Inference] Onboard with 'Start Ollama on Windows host' fails at [4/8] — auth proxy at host.openshell.internal:11435 not started #4421 asks NemoClaw to start an auth proxy on the WSL host, make host.openshell.internal:11435 reachable from Docker containers, proceed through onboarding, create a sandbox, and prove inference end-to-end. This patch instead classifies native Docker/Podman/Colima/unknown WSL runtimes as unsupported and rejects those provider selections before launch/model selection. That can be a valid product decision for native-Docker WSL, but it does not satisfy the literal Fixes-linked completion clauses.
  • Recommendation: Either implement and test the requested native-Docker WSL Windows-host Ollama auth-proxy path, including sandbox reachability and completion through sandbox creation, or narrow the PR/issue linkage and release-note scope so this PR is explicitly a clear unsupported-topology rejection rather than a fix for the full onboard/sandbox completion issues.
  • Evidence: [WSL2 x86_64][Inference] Onboard with 'Start Ollama on Windows host' fails at [4/8] — auth proxy at host.openshell.internal:11435 not started #4421 Expected Result says: "Wizard creates an auth proxy listening on the WSL host at port 11435", "The proxy forwards sandbox requests to Win-host Ollama on 11434", "host.openshell.internal:11435 is reachable from Docker containers", "Onboard advances to [5/8] and through to [8/8]", and "A sandbox is created and inference works end-to-end". The diff adds getWindowsHostOllamaDockerRequirement()/rejectUnsupportedWindowsHostOllama() and tests assert native Docker WSL rejects start-windows-ollama, install-windows-ollama, and reachable generic ollama before Windows side effects or model selection.

🔎 Worth checking

• Source-of-truth review needed: Native Docker WSL + Windows-host Ollama compatibility gate: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: local-inference-topology.ts labels unsupported runtimes with `requires Docker Desktop WSL integration` and prints `Native Docker-in-WSL cannot reliably route sandbox containers to Windows-host Ollama.`
• Native-Docker WSL Windows-host Ollama gate still needs a source-of-truth decision (src/lib/onboard/local-inference-topology.ts:124): The new compatibility gate is localized workaround/product-boundary behavior for a topology that linked issues describe as a missing auth-proxy/forwarding implementation. The code now has labels, fail-fast behavior, and regression tests, but it still does not record whether native Docker WSL plus Windows-host Ollama is intentionally unsupported, why the requested auth-proxy-on-11435 source fix is out of scope for this PR, or when the gate should be removed.
  • Recommendation: Document the source-of-truth decision in code, docs, or issue scope: the invalid state handled, why the auth-proxy-on-11435 source fix is not being done here, which runtime validation proves the unsupported boundary, and the removal condition if native Docker WSL support is later implemented.
  • Evidence: The unsupported path prints "Native Docker-in-WSL cannot reliably route sandbox containers to Windows-host Ollama" and marks all WSL runtimes except docker-desktop unsupported. [WSL2 x86_64][Inference] Onboard with 'Start Ollama on Windows host' fails at [4/8] — auth proxy at host.openshell.internal:11435 not started #4421 instead reports endpointUrl=http://host.openshell.internal:11435/v1 with no proxy listening and expects that proxy to be started.
• Recorded-provider recovery hint can still recommend a provider that now aborts (src/lib/onboard.ts:4166): When a recorded WSL-local ollama-local provider is unavailable but Windows-host Ollama is reachable, the recovery path still tells the user to rerun with NEMOCLAW_PROVIDER=ollama. On native Docker WSL, this PR now rejects that explicit provider because Windows-host Ollama requires Docker Desktop WSL integration, so the hint can send users into a guaranteed abort without mentioning the new requirement.
  • Recommendation: Make this recovery hint runtime-aware. If the current WSL container runtime does not satisfy getWindowsHostOllamaDockerRequirement(), tell users to choose WSL-local Ollama or enable Docker Desktop WSL integration instead of suggesting NEMOCLAW_PROVIDER=ollama.
  • Evidence: The code path checks isWsl() && recordedProvider === "ollama-local" && isWindowsHostOllama and prints "Hint: Windows-host Ollama is reachable here; re-run with NEMOCLAW_PROVIDER=ollama to use it explicitly." Later, the ollama branch calls rejectWindowsHostOllama(selected.key, isWindowsHostOllama), which aborts when the requirement is unsupported.

🌱 Nice ideas

• None.

Since last review details

Current findings:

• Source-of-truth review needed: Native Docker WSL + Windows-host Ollama compatibility gate: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: local-inference-topology.ts labels unsupported runtimes with `requires Docker Desktop WSL integration` and prints `Native Docker-in-WSL cannot reliably route sandbox containers to Windows-host Ollama.`
• PR links fixes for Windows-host Ollama completion issues but implements an unsupported-topology gate (src/lib/onboard/local-inference-topology.ts:67): The PR body says it fixes [WSL2][Onboard] install exits 1 after start-windows-ollama / install-windows-ollama provider handoff succeeds #4208, [NemoClaw][Onboard][Windows] nemoclaw onboard stops after step [4/8]; no sandbox created even though Ollama is responsive #4257, and [WSL2 x86_64][Inference] Onboard with 'Start Ollama on Windows host' fails at [4/8] — auth proxy at host.openshell.internal:11435 not started #4421. The most direct linked acceptance in [WSL2 x86_64][Inference] Onboard with 'Start Ollama on Windows host' fails at [4/8] — auth proxy at host.openshell.internal:11435 not started #4421 asks NemoClaw to start an auth proxy on the WSL host, make host.openshell.internal:11435 reachable from Docker containers, proceed through onboarding, create a sandbox, and prove inference end-to-end. This patch instead classifies native Docker/Podman/Colima/unknown WSL runtimes as unsupported and rejects those provider selections before launch/model selection. That can be a valid product decision for native-Docker WSL, but it does not satisfy the literal Fixes-linked completion clauses.
  • Recommendation: Either implement and test the requested native-Docker WSL Windows-host Ollama auth-proxy path, including sandbox reachability and completion through sandbox creation, or narrow the PR/issue linkage and release-note scope so this PR is explicitly a clear unsupported-topology rejection rather than a fix for the full onboard/sandbox completion issues.
  • Evidence: [WSL2 x86_64][Inference] Onboard with 'Start Ollama on Windows host' fails at [4/8] — auth proxy at host.openshell.internal:11435 not started #4421 Expected Result says: "Wizard creates an auth proxy listening on the WSL host at port 11435", "The proxy forwards sandbox requests to Win-host Ollama on 11434", "host.openshell.internal:11435 is reachable from Docker containers", "Onboard advances to [5/8] and through to [8/8]", and "A sandbox is created and inference works end-to-end". The diff adds getWindowsHostOllamaDockerRequirement()/rejectUnsupportedWindowsHostOllama() and tests assert native Docker WSL rejects start-windows-ollama, install-windows-ollama, and reachable generic ollama before Windows side effects or model selection.
• Native-Docker WSL Windows-host Ollama gate still needs a source-of-truth decision (src/lib/onboard/local-inference-topology.ts:124): The new compatibility gate is localized workaround/product-boundary behavior for a topology that linked issues describe as a missing auth-proxy/forwarding implementation. The code now has labels, fail-fast behavior, and regression tests, but it still does not record whether native Docker WSL plus Windows-host Ollama is intentionally unsupported, why the requested auth-proxy-on-11435 source fix is out of scope for this PR, or when the gate should be removed.
  • Recommendation: Document the source-of-truth decision in code, docs, or issue scope: the invalid state handled, why the auth-proxy-on-11435 source fix is not being done here, which runtime validation proves the unsupported boundary, and the removal condition if native Docker WSL support is later implemented.
  • Evidence: The unsupported path prints "Native Docker-in-WSL cannot reliably route sandbox containers to Windows-host Ollama" and marks all WSL runtimes except docker-desktop unsupported. [WSL2 x86_64][Inference] Onboard with 'Start Ollama on Windows host' fails at [4/8] — auth proxy at host.openshell.internal:11435 not started #4421 instead reports endpointUrl=http://host.openshell.internal:11435/v1 with no proxy listening and expects that proxy to be started.
• Recorded-provider recovery hint can still recommend a provider that now aborts (src/lib/onboard.ts:4166): When a recorded WSL-local ollama-local provider is unavailable but Windows-host Ollama is reachable, the recovery path still tells the user to rerun with NEMOCLAW_PROVIDER=ollama. On native Docker WSL, this PR now rejects that explicit provider because Windows-host Ollama requires Docker Desktop WSL integration, so the hint can send users into a guaranteed abort without mentioning the new requirement.
  • Recommendation: Make this recovery hint runtime-aware. If the current WSL container runtime does not satisfy getWindowsHostOllamaDockerRequirement(), tell users to choose WSL-local Ollama or enable Docker Desktop WSL integration instead of suggesting NEMOCLAW_PROVIDER=ollama.
  • Evidence: The code path checks isWsl() && recordedProvider === "ollama-local" && isWindowsHostOllama and prints "Hint: Windows-host Ollama is reachable here; re-run with NEMOCLAW_PROVIDER=ollama to use it explicitly." Later, the ollama branch calls rejectWindowsHostOllama(selected.key, isWindowsHostOllama), which aborts when the requirement is unsupported.

Workflow run details

This is an automated advisory review. A human maintainer must make the final merge decision.

[coderabbitai]

🧹 Nitpick comments (2)

src/lib/onboard/local-inference-topology.ts (1)

67-131: Run the targeted onboarding E2E subset before merge.

Given this changes WSL runtime gating for provider selection, run the recommended onboarding/cloud lifecycle suite to validate end-to-end behavior under real topology transitions.

As per coding guidelines: "E2E test recommendation: cloud-e2e, sandbox-operations-e2e, rebuild-openclaw-e2e, channels-stop-start-e2e, messaging-compatible-endpoint-e2e, bedrock-runtime-compatible-anthropic-e2e, hermes-discord-e2e, hermes-slack-e2e, openshell-gateway-upgrade-e2e, issue-3600-gpu-proof-optional-e2e".

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/onboard/local-inference-topology.ts` around lines 67 - 131, Change to
WSL runtime gating in getWindowsHostOllamaDockerRequirement affects provider
selection; before merging, run the targeted onboarding E2E subset to validate
real topology transitions and attach results. Execute the recommended suites:
cloud-e2e, sandbox-operations-e2e, rebuild-openclaw-e2e,
channels-stop-start-e2e, messaging-compatible-endpoint-e2e,
bedrock-runtime-compatible-anthropic-e2e, hermes-discord-e2e, hermes-slack-e2e,
openshell-gateway-upgrade-e2e, and issue-3600-gpu-proof-optional-e2e against
this branch (or in your CI job) and ensure all pass for changes in
getWindowsHostOllamaDockerRequirement; if any fail, reproduce locally, fix the
gating logic or messaging, and re-run until green, then upload logs/results to
the PR.

src/lib/onboard.ts (1)

4896-4906: Run the recommended onboarding E2E suite before merge.

This guardrail touches core provider-selection flow and non-interactive rejection paths, so run the selective nightly E2E job set for onboard/rebuild/channel/provider regressions:

gh workflow run nightly-e2e.yaml --ref <branch> -f jobs=cloud-e2e,sandbox-operations-e2e,rebuild-openclaw-e2e,channels-stop-start-e2e,messaging-compatible-endpoint-e2e,bedrock-runtime-compatible-anthropic-e2e,hermes-discord-e2e,hermes-slack-e2e,openshell-gateway-upgrade-e2e,issue-3600-gpu-proof-optional-e2e

As per coding guidelines: src/lib/onboard.ts is core onboarding logic and includes an explicit E2E test recommendation list for this area.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/onboard.ts` around lines 4896 - 4906, This change affects the
provider-selection/non-interactive rejection flow around
windowsHostOllamaDockerRequirement (used with selected.key, reject,
isNonInteractive, abortNonInteractive and selectionLoop); before merging, run
the recommended selective nightly E2E suite listed in the review (jobs:
cloud-e2e,sandbox-operations-e2e,rebuild-openclaw-e2e,channels-stop-start-e2e,messaging-compatible-endpoint-e2e,bedrock-runtime-compatible-anthropic-e2e,hermes-discord-e2e,hermes-slack-e2e,openshell-gateway-upgrade-e2e,issue-3600-gpu-proof-optional-e2e)
against this branch to verify provider selection and non-interactive rejection
behavior, and only merge if those E2E runs pass.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/lib/onboard.ts`:
- Around line 4896-4906: This change affects the
provider-selection/non-interactive rejection flow around
windowsHostOllamaDockerRequirement (used with selected.key, reject,
isNonInteractive, abortNonInteractive and selectionLoop); before merging, run
the recommended selective nightly E2E suite listed in the review (jobs:
cloud-e2e,sandbox-operations-e2e,rebuild-openclaw-e2e,channels-stop-start-e2e,messaging-compatible-endpoint-e2e,bedrock-runtime-compatible-anthropic-e2e,hermes-discord-e2e,hermes-slack-e2e,openshell-gateway-upgrade-e2e,issue-3600-gpu-proof-optional-e2e)
against this branch to verify provider selection and non-interactive rejection
behavior, and only merge if those E2E runs pass.

In `@src/lib/onboard/local-inference-topology.ts`:
- Around line 67-131: Change to WSL runtime gating in
getWindowsHostOllamaDockerRequirement affects provider selection; before
merging, run the targeted onboarding E2E subset to validate real topology
transitions and attach results. Execute the recommended suites: cloud-e2e,
sandbox-operations-e2e, rebuild-openclaw-e2e, channels-stop-start-e2e,
messaging-compatible-endpoint-e2e, bedrock-runtime-compatible-anthropic-e2e,
hermes-discord-e2e, hermes-slack-e2e, openshell-gateway-upgrade-e2e, and
issue-3600-gpu-proof-optional-e2e against this branch (or in your CI job) and
ensure all pass for changes in getWindowsHostOllamaDockerRequirement; if any
fail, reproduce locally, fix the gating logic or messaging, and re-run until
green, then upload logs/results to the PR.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 9d233917-c4d8-4b92-b238-1f475db88af8

📥 Commits

Reviewing files that changed from the base of the PR and between 0c108ae and 7e9917b.

📒 Files selected for processing (4)

• src/lib/onboard.ts
• src/lib/onboard/local-inference-topology.ts
• src/lib/onboard/ollama-install-menu.ts
• test/onboard-selection.test.ts

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/lib/onboard.ts (1)

4160-4166: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Guard the Windows-host hint behind supported topology.

This branch now tells users to rerun with NEMOCLAW_PROVIDER=ollama, but the ollama path is rejected later when windowsHostOllamaDockerRequirement.supported is false. In the native-Docker-in-WSL case, that turns this recovery hint into another immediate abort. Only show that hint when the Windows-host path is actually supported; otherwise surface the same unsupported-topology guidance used by the new guardrail.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/onboard.ts` around lines 4160 - 4166, In the branch starting with if
(isWsl() && recordedProvider === "ollama-local" && isWindowsHostOllama) adjust
the recovery hint so it is only shown when the Windows-host path is actually
supported: check windowsHostOllamaDockerRequirement.supported and, if true, log
the "re-run with NEMOCLAW_PROVIDER=ollama" hint; otherwise log the same
unsupported-topology guidance used by the guardrail (the message shown when the
topology is unsupported). This ensures the suggestion to use ollama on the
Windows host is only displayed when windowsHostOllamaDockerRequirement.supported
is true.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@src/lib/onboard.ts`:
- Around line 4160-4166: In the branch starting with if (isWsl() &&
recordedProvider === "ollama-local" && isWindowsHostOllama) adjust the recovery
hint so it is only shown when the Windows-host path is actually supported: check
windowsHostOllamaDockerRequirement.supported and, if true, log the "re-run with
NEMOCLAW_PROVIDER=ollama" hint; otherwise log the same unsupported-topology
guidance used by the guardrail (the message shown when the topology is
unsupported). This ensures the suggestion to use ollama on the Windows host is
only displayed when windowsHostOllamaDockerRequirement.supported is true.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: aa4d47a3-02ce-468c-9f8e-6f48c6513932

📥 Commits

Reviewing files that changed from the base of the PR and between 7e9917b and c55b6fd.

📒 Files selected for processing (7)

• src/lib/onboard.ts
• src/lib/onboard/local-inference-topology.ts
• src/lib/onboard/ollama-install-menu.test.ts
• src/lib/onboard/ollama-install-menu.ts
• src/lib/onboard/provider-key-fallback.test.ts
• src/lib/onboard/provider-key-fallback.ts
• test/onboard-selection.test.ts

🚧 Files skipped from review as they are similar to previous changes (2)

• src/lib/onboard/ollama-install-menu.ts
• src/lib/onboard/local-inference-topology.ts

dismissed — posted without maintainer authorization

dismissed — approval body referenced local test verification, but I'm on macOS and unit-tested with mocked WSL topology, so real-world WSL/native-docker behavior is not actually verified. need WSL repro before approving.

[coderabbitai]

Actionable comments posted: 0

[cjagwani]

Clean extraction — onboard.ts net-neutral (+61/-61), new helpers are testable and the discriminated union forces exhaustive handling at call sites. Build green, unit tests pass on macOS (ollama-install-menu.test.ts, provider-key-fallback.test.ts, onboard-selection.test.ts).

No Windows host to verify the three Fixes-linked reproducers (#4208, #4421, #4257) end-to-end — flagging that as a QA spot-check before merge, not a code-review concern.

[cjagwani]

Approving on the strength of @zifu Yang's WSL2 + native-Docker-in-WSL verification: option 7 now correctly carries the "(requires Docker Desktop WSL integration)" label suffix, and selecting it produces the actionable detected native Docker Engine in WSL abort instead of continuing into the broken step-[4/8] state. That's #4421's exact reproducer landing on the new clean reject path as designed.

Code review + unit tests pass on macOS; my own platform constraint is now covered by Zifu's real-Windows run.