1. src/daemon/schtasks.ts, line 748-761 (link)

   Unhandled spawn errors no longer caught

   The removed try-catch block also handled the case where execSchtasks itself throws — specifically when the schtasks.exe binary is missing and Node's spawn emits an error event (ENOENT). Looking at runCommandWithTimeout, the child.on("error", ...) handler calls reject(err), which propagates through execSchtasks as a thrown exception.

   In the old code this was caught by the try-catch around assertSchtasksAvailable(), and the function would either fall back to the startup-entry runtime or return { status: "unknown", detail: String(err) }. With the preflight removed, a spawn error now propagates uncaught out of readScheduledTaskRuntime.

   In practice schtasks.exe is always present on Windows, so this is an extreme edge case. But if defensive coverage matters here (consistent with the pattern in stopScheduledTask and restartScheduledTask), you could wrap the execSchtasks call:

     const res = await execSchtasks(["/Query", "/TN", taskName, "/V", "/FO", "LIST"]).catch(
       (err: unknown): { code: number; stdout: string; stderr: string } => ({
         code: 1,
         stdout: "",
         stderr: String(err),
       }),
     );
   

   This keeps the rest of the non-zero-code handling intact without reintroducing the preflight.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/daemon/schtasks.ts
   Line: 748-761
   
   Comment:
   **Unhandled spawn errors no longer caught**
   
   The removed `try-catch` block also handled the case where `execSchtasks` itself throws — specifically when the `schtasks.exe` binary is missing and Node's `spawn` emits an `error` event (ENOENT). Looking at `runCommandWithTimeout`, the `child.on("error", ...)` handler calls `reject(err)`, which propagates through `execSchtasks` as a thrown exception.
   
   In the old code this was caught by the `try-catch` around `assertSchtasksAvailable()`, and the function would either fall back to the startup-entry runtime or return `{ status: "unknown", detail: String(err) }`. With the preflight removed, a spawn error now propagates uncaught out of `readScheduledTaskRuntime`.
   
   In practice `schtasks.exe` is always present on Windows, so this is an extreme edge case. But if defensive coverage matters here (consistent with the pattern in `stopScheduledTask` and `restartScheduledTask`), you could wrap the `execSchtasks` call:
   
   ```
     const res = await execSchtasks(["/Query", "/TN", taskName, "/V", "/FO", "LIST"]).catch(
       (err: unknown): { code: number; stdout: string; stderr: string } => ({
         code: 1,
         stdout: "",
         stderr: String(err),
       }),
     );
   ```
   
   This keeps the rest of the non-zero-code handling intact without reintroducing the preflight.
   
   How can I resolve this? If you propose a fix, please make it concise.

Best possible solution:

Land the narrow patch after exact-head CI is green and someone adds redacted live Windows openclaw status or scheduled-task proof showing the named-task query path succeeds or falls back as intended.

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

Yes. Source inspection of current main shows a high-confidence mocked reproduction path: make broad schtasks /Query fail while /Query /TN "OpenClaw Gateway" /V /FO LIST would succeed or a Startup fallback exists; I did not run a live Windows scheduled task.

Is this the best way to solve the issue?

Yes for the code direction. Removing only the runtime-status preflight while preserving task-scoped failure fallback is the narrow maintainable fix, but merge readiness still depends on real behavior proof and final CI.

What I checked:

• Current main still preflights runtime status: On current main, readScheduledTaskRuntime() calls assertSchtasksAvailable() before the named /Query /TN ... /V /FO LIST query, so a broad /Query failure can stop status before the data-bearing lookup. (src/daemon/schtasks.ts:1028, cf0f1a171a04)
• Windows status path uses the runtime reader: The win32 gateway service adapter wires readRuntime to readScheduledTaskRuntime, so the change affects Windows gateway status reads. (src/daemon/service.ts:277, cf0f1a171a04)
• PR head implements the direct task query: The PR head queries /Query /TN <taskName> /V /FO LIST directly and maps thrown execSchtasks errors into the existing non-zero/fallback handling. (src/daemon/schtasks.ts:1028, b80ae7a0dabf)
• Regression coverage locks the intended behavior: The refreshed tests assert a single task-scoped schtasks call with no global preflight and cover thrown-query fallback to Startup runtime. (src/daemon/schtasks.startup-fallback.test.ts:401, b80ae7a0dabf)
• Changelog entry present: The PR adds a user-facing Gateway/Windows changelog entry for the status fix and credits the external contributor. (CHANGELOG.md:67, b80ae7a0dabf)
• Real behavior proof is still missing: The PR body says live Windows scheduled-task verification was not run; the maintainer refresh comment lists format, oxlint, and Vitest checks only; GitHub currently reports the Real behavior proof check as failing. (b80ae7a0dabf)

Likely related people:

• steipete: Recent current-main history repeatedly touches Windows schtasks lifecycle, startup fallback, and daemon service flow around this runtime status path. (role: recent maintainer and likely follow-up owner; confidence: high; commits: 13f9deb61979, fccb2b8ace6c, 0fb9a3beacc2; files: src/daemon/schtasks.ts, src/daemon/schtasks.startup-fallback.test.ts, src/daemon/service.ts)
• tmimmanuel: Authored the merged Windows scheduled-task restart/install behavior work and related startup-fallback test updates near this code path. (role: adjacent feature-history owner; confidence: medium; commits: 0fef95b17d72; files: src/daemon/schtasks.ts, src/daemon/schtasks.startup-fallback.test.ts)
• vincentkoc: Recently touched src/daemon/service.ts, whose win32 adapter routes gateway status into readScheduledTaskRuntime. (role: recent gateway service maintainer; confidence: medium; commits: 97d35f4c575b; files: src/daemon/service.ts)
• BradGroux: Force-pushed the current prepared head and documented the local verification now waiting on CI/proof. (role: maintainer refresh owner; confidence: high; commits: b80ae7a0dabf; files: src/daemon/schtasks.ts, src/daemon/schtasks.startup-fallback.test.ts, CHANGELOG.md)

Remaining risk / open question:

• External after-fix proof from a real Windows scheduled-task setup is still missing; the PR body explicitly says live verification was not run and the proof check is failing.
• One exact-head CI check was still in progress at review time.

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