Best possible solution:

Land the narrow fallback after adding a changelog entry and maintainer review confirms the short early-exit polling window is acceptable.

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

Yes for the unit-level failure shape: the PR models schtasks /Run success followed by Last Run Result: 0 / Ready with no listener and expects the fallback launcher. Live Windows reproduction is not present in this read-only review.

Is this the best way to solve the issue?

Yes for the code direction: it reuses the existing launch-evidence checks and Startup-style detached fallback instead of adding a new Windows service path. It is not merge-ready until the required changelog entry and maintainer review are handled.

Full review comments:

• [P3] Add the required changelog entry — src/daemon/schtasks.ts:228
  This changes user-facing Windows gateway startup/restart behavior, but the PR does not update CHANGELOG.md. OpenClaw policy requires a single-line changelog entry for user-facing fixes before landing.
  Confidence: 0.91

Overall correctness: patch is correct
Overall confidence: 0.82

What I checked:

• Current main behavior: shouldFallbackScheduledTaskLaunch() on current main only enters the fallback path when the launch observation remains not-yet-run; Last Run Result=0 is treated as other and returns without fallback. (src/daemon/schtasks.ts:783, 10448a0ad14c)
• PR implementation: The PR diff adds a stopped-success state for normalized 0x0, polls briefly for listener/process evidence, then reuses the existing detached fallback launcher when no launch evidence appears. (src/daemon/schtasks.ts:695, 8f4ef7b32d67)
• PR test coverage: The PR adds a regression test where /Run succeeds, the task reports Status: Ready and Last Run Result: 0, and the Startup-style fallback spawn is expected. (src/daemon/schtasks.startup-fallback.test.ts:165, 8f4ef7b32d67)
• Windows docs boundary: The Windows docs describe Scheduled Tasks as the preferred native Windows service path with a per-user Startup-folder fallback when Scheduled Task creation is blocked. Public docs: docs/platforms/windows.md. (docs/platforms/windows.md:40, 10448a0ad14c)
• Changelog check: No changelog entry mentions the new early-exit / Last Run Result=0 fallback shape, even though this is a user-facing Windows gateway fix. (CHANGELOG.md:1, 10448a0ad14c)
• PR state: GitHub API reports the PR is draft, has the maintainer label, and is not merged; checks are mostly skipped with no substantive target test proof visible from check-runs. (8f4ef7b32d67)

Likely related people:

• steipete: Repeated recent commits introduced and maintained the Windows Scheduled Task / Startup-folder fallback behavior and its tests, including the Startup fallback, direct launcher, and managed-env drift audit. (role: recent maintainer and feature-history owner; confidence: high; commits: 433e65711f78, 32d8ec948262, fccb2b8ace6c; files: src/daemon/schtasks.ts, src/daemon/schtasks.startup-fallback.test.ts)
• tmimmanuel: Prior merged work preserved Windows scheduled-task restart/install behavior in the same daemon area, which is directly adjacent to this fallback path. (role: adjacent owner; confidence: medium; commits: 0fef95b17d72; files: src/daemon/schtasks.ts, src/daemon/schtasks.startup-fallback.test.ts)

Remaining risk / open question:

• No live Windows Task Scheduler run was performed in this read-only review; assessment is based on current source, PR diff, tests, docs, and PR-stated validation.
• The 2s early-exit polling window is a product/runtime judgment for slow Windows hosts and should be confirmed by the gateway maintainer before landing.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 10448a0ad14c.