Clarify unavailable Local AI setup states

[karkarl]

Summary

• show Local AI availability as a green Local AI icon badge beside Recommended on the local WSL gateway choice
• place the unavailable Local AI InfoBar above the Local AI on this PC card as a sibling, with built-in InfoBar message/action layout so there is no extra title-to-message gap
• gray and disable dependent setup content while keeping See why independently usable
• add the same unavailable InfoBar and disabled option-tile behavior to the Local AI hub page
• share eligibility diagnostics between setup and the hub, with localized hub copy and focused accessibility/state tests

Validation

• .\build.ps1 -DevBuild - passed (Shared, CLI, WinNode CLI, SetupEngine, WinUI)
• dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --no-restore - passed: 3,812, skipped: 32, failed: 0
• dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restore - passed: 2,708, failed: 0
• dotnet test .\tests\OpenClaw.Tray.UITests\OpenClaw.Tray.UITests.csproj --no-restore -r win-arm64 - passed: 134, failed: 0
• focused Local AI UX, view-model, localization, accessibility, and composition tests - passed: 29, failed: 0
• rubber-duck review completed; initial-state flash, model-specific eligibility, and duplicate screen-reader announcement findings were fixed; follow-up InfoBar hierarchy review found no issues

Real behavior proof

Current-head commit 03c5deff is running in the isolated setup preview:

OPENCLAW_SETUP_PREVIEW_PAGE=capabilities-review
.\run-app-local.ps1 -Dev -Isolated -AllowNonMain
Started OpenClaw Tray (PID: 41928)
Window: OpenClaw Setup (Dev), responding

Live UI Automation confirms the sibling InfoBar renders completely above the disabled Local AI choice and keeps its action enabled:

LocalAiUnavailablePanel|enabled=True|top=700|bottom=835
LocalAiUnavailableDetailsButton|name=See why|enabled=True|top=787|bottom=813
LocalAiSetupToggle|name=Set up Local AI on this PC|enabled=False|top=865|bottom=916

The InfoBar bottom at 835 is above the Local AI card control beginning at 865. Invoking See why exposes the live hardware reason without enabling the dependent setup choice:

Why Local AI is unavailable
Hardware: No NVIDIA GPU was reported by the NVIDIA driver. Install or repair the NVIDIA driver, then try setup again.

Available and unavailable projection behavior is also covered by LocalAiPageViewModelTests; XAML placement, built-in InfoBar message/action layout, badge icon/state, disabled controls, and action separation are covered by LocalAiSetupUxContractTests; the real WinUI accessibility suite passed on ARM64.

Screenshots: Not verified / blocked. No computer-use tool is exposed in this session. Native PrintWindow and desktop capture could see the responding OpenClaw Setup HWND but did not expose the WinUI surface, so no misleading screenshot is attached.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs changes before merge. Reviewed August 21, 2026, 9:37 PM ET / August 22, 2026, 01:37 UTC.

ClawSweeper review

What this changes

This PR adds unavailable-Local-AI guidance, disabled setup choices, shared diagnostics, and accessibility coverage to setup and the Local AI settings page.

Regression provenance

Possible regression — suspected (reviewed change). No predecessor PR is attributed.

Merge readiness

⚠️ Ready for maintainer review - 3 items remain

Keep open. The prior P1 blocker remains: an unavailable fresh GPU probe disables management of an already-running Local AI runtime, contradicting current-main behavior.

Priority: P2
Reviewed head: 03c5deff01ff51906e30c3d2c4ec1013cf013759

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The PR has useful current-head setup proof and focused tests, but the remaining P1 compatibility regression prevents merge readiness.
Proof confidence	🐚 platinum hermit (4/6)	Not applicable: The contributor proof gate does not apply to this collaborator PR; the body nevertheless provides current-head setup UI Automation output, but it does not cover the hub-management invariant.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The contributor proof gate does not apply to this collaborator PR; the body nevertheless provides current-head setup UI Automation output, but it does not cover the hub-management invariant.
Evidence reviewed	6 items	Current-head management regression: The new availability predicate gates Stop, Restart, Open logs, Retry setup, Repair connection, and Open chat. A healthy companion-managed runtime becomes unmanageable after a later failed hardware probe. UI also disables every action card: The new page refresh disables each enclosing option control, which disables all descendant management buttons regardless of their individual action predicates. Regression test encodes the unwanted outcome: The new unsupported-hardware test uses a healthy companion-managed runtime, then asserts that Stop, logs, and connection repair are unavailable.
Findings	1 actionable finding	[P1] Keep Local AI management controls available after probe failure
Security	None	None.

Live Verification

Command: .\run-app-local.ps1 -Dev -Isolated -AllowNonMain

Result: FAIL (failed) — execution before step 1 run: sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

Assertions:

• FAIL expect_output: Started OpenClaw Tray

How this fits together

Local AI eligibility combines the detected Windows GPU and the selected model requirements. Setup and the Local AI hub consume that result to present installation choices, diagnostics, and runtime controls.

flowchart LR
  A[Windows GPU probe] --> B[Local AI eligibility]
  C[Selected model] --> B
  B --> D[Unavailable diagnostics]
  D --> E[Setup review]
  D --> F[Local AI hub]
  F --> G[Runtime management actions]

Loading

Before merge

• Keep Local AI management controls available after probe failure (P1) - The new availability gate is applied both to the action predicates and each enclosing card. A companion-managed router can remain healthy after NVML fails or the driver changes, but this makes Stop, Restart, Open logs, and Repair connection unavailable even though current main allows them from runtime and gateway state. Keep the eligibility gate for fresh setup choices, not existing-runtime management.
• Resolve merge risk (P1) - Merging can strand users with a healthy companion-managed Local AI process when a later GPU probe fails, because Stop, Restart, Open logs, and connection recovery become unavailable.
• Complete next step (P2) - The remaining P1 is a narrow mechanical repair: unavailable eligibility must not suppress existing Local AI lifecycle, diagnostic, or connection-recovery controls.

Findings

• [P1] Keep Local AI management controls available after probe failure — src/OpenClaw.Tray.WinUI/Pages/LocalAiPage.xaml.cs:95-97

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and test delta	production +329/-138, tests +329/-12	The UI change spans setup, tray presentation, diagnostics, localization, and matching focused tests.

Merge-risk options

Maintainer options:

1. Preserve existing runtime management (recommended)
   Separate unavailable-install presentation from management controls so a failed eligibility refresh cannot block an existing runtime's stop, logs, restart, or connection-recovery paths.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Restore current-main management predicates for an existing companion-managed runtime after an unavailable hardware probe, split any disabled container so those controls remain operable, and add focused regressions.

Technical review

Best possible solution:

Keep eligibility gating for fresh Local AI setup, but preserve runtime lifecycle, diagnostics, and connection-recovery controls for an already-installed managed runtime, with regression coverage for a failed probe.

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

Yes, from source with high confidence: the new test constructs a healthy companion-managed runtime plus an unavailable probe and confirms the affected actions become false.

Is this the best way to solve the issue?

No. The current approach conflates eligibility for new setup with management of an existing runtime; those states need separate enablement rules.

Full review comments:

• [P1] Keep Local AI management controls available after probe failure — src/OpenClaw.Tray.WinUI/Pages/LocalAiPage.xaml.cs:95-97
  The new availability gate is applied both to the action predicates and each enclosing card. A companion-managed router can remain healthy after NVML fails or the driver changes, but this makes Stop, Restart, Open logs, and Repair connection unavailable even though current main allows them from runtime and gateway state. Keep the eligibility gate for fresh setup choices, not existing-runtime management.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.99

AGENTS.md: found and applied where relevant.

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

Labels

Label justifications:

• P2: The PR introduces a bounded but user-visible Local AI runtime-management regression.
• merge-risk: 🚨 compatibility: Existing managed Local AI installations can lose their previously available recovery and diagnostic controls after upgrade.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The contributor proof gate does not apply to this collaborator PR; the body nevertheless provides current-head setup UI Automation output, but it does not cover the hub-management invariant.

Evidence

Acceptance criteria:

• [P1] ./build.ps1.
• [P1] dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Tray.UITests/OpenClaw.Tray.UITests.csproj --no-restore -r win-arm64.
• [P1] Run an isolated Local AI hub proof showing unavailable setup state with runtime management controls still usable.

What I checked:

• Current-head management regression: The new availability predicate gates Stop, Restart, Open logs, Retry setup, Repair connection, and Open chat. A healthy companion-managed runtime becomes unmanageable after a later failed hardware probe. (src/OpenClaw.Tray.WinUI/Presentation/LocalAiPageViewModel.cs:127, 03c5deff01ff)
• UI also disables every action card: The new page refresh disables each enclosing option control, which disables all descendant management buttons regardless of their individual action predicates. (src/OpenClaw.Tray.WinUI/Pages/LocalAiPage.xaml.cs:95, 03c5deff01ff)
• Regression test encodes the unwanted outcome: The new unsupported-hardware test uses a healthy companion-managed runtime, then asserts that Stop, logs, and connection repair are unavailable. (tests/OpenClaw.Tray.Tests/Presentation/LocalAiPageViewModelTests.cs:42, 03c5deff01ff)
• Current-main baseline: Current main permits lifecycle, diagnostics, and connection actions from runtime and gateway state without a fresh eligibility gate. (src/OpenClaw.Tray.WinUI/Presentation/LocalAiPageViewModel.cs:113, ccd64bbb7d68)
• Feature provenance: The Local AI hub and setup flow were introduced by the current-main Local AI feature commit; its history identifies the central feature ownership trail. (src/OpenClaw.Tray.WinUI/Presentation/LocalAiPageViewModel.cs:15, ccd64bbb7d68)
• Current-head proof: The PR body supplies current-head UI Automation output for the setup InfoBar, its enabled See why action, and the disabled setup toggle. This does not establish the Local AI hub management-action invariant. (03c5deff01ff)

Likely related people:

• Joel: Authored the current-main managed Local AI feature that introduced the hub view model and setup flow. (role: feature introducer; confidence: high; commits: ccd64bbb7d68; files: src/OpenClaw.Tray.WinUI/Presentation/LocalAiPageViewModel.cs, src/OpenClaw.SetupEngine.UI/Pages/CapabilitiesPage.xaml.cs)
• karkarl: Credited in the merged Local AI feature history and authored the current refinement. (role: recent Local AI contributor; confidence: medium; commits: ccd64bbb7d68, 03c5deff01ff; files: src/OpenClaw.Tray.WinUI/Presentation/LocalAiPageViewModel.cs, src/OpenClaw.SetupEngine.UI/Pages/CapabilitiesPage.xaml)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Restore management actions for a healthy companion-managed runtime when eligibility becomes unavailable, and reverse the conflicting test expectations.
• Capture current-head hub proof showing unavailable setup choices alongside usable Stop, Open logs, and Repair connection controls.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.

History

Review history (1 earlier review cycle)

• reviewed 2026-08-22T00:06:48.325Z sha a1ea2ce :: needs changes before merge. :: [P1] Preserve management actions when eligibility fails

[TheAngryPit]

ClawSweeper's P1 is fixed in #1206. The patch is based on exact head 03c5def, keeps hardware eligibility limited to fresh setup, preserves management of an installed runtime, and includes failed-first coverage plus full build, Shared (3812 passed), Tray (2711 passed), and independent review. Please merge #1206 into this branch, then trigger a fresh ClawSweeper review on #1204.