Greptile Summary

This PR fixes #49187 by removing the unnecessary global schtasks /Query preflight from readScheduledTaskRuntime() in src/daemon/schtasks.ts. The function only ever needed the task-scoped query result, so the broad preflight was an extra round-trip that could fail independently of whether the task-scoped query would succeed, causing false-negative status reads.

Key changes:

• readScheduledTaskRuntime now goes directly to schtasks /Query /TN <taskName> /V /FO LIST — the startup-folder fallback is still triggered when that task-scoped query returns non-zero.
• addStartupFallbackMissingResponses in the test helper gains an { includePreflight } opt-in so callers that exercise code paths still using assertSchtasksAvailable() (e.g., restartScheduledTask) can push the extra fixture response without affecting tests that should not see a preflight.
• A new regression test ("reads runtime from the task-scoped schtasks query without a global preflight") locks in the single-call behavior and asserts on the exact argument array.

One minor robustness note: the removed try-catch also silently handled the edge case where schtasks.exe is not found at all (ENOENT spawn error), falling back to the startup-entry runtime or returning { status: "unknown" }. With the preflight gone, that spawn-level exception now propagates uncaught from readScheduledTaskRuntime. On a real Windows system schtasks.exe is always present, so this is an extreme edge case, but it is a subtle behavior change from the previous code.

Confidence Score: 5/5

• Safe to merge — the change is narrowly scoped, the logic is correct, and the test coverage directly validates the intended behavior.
• The core change (removing the redundant preflight) is correct and well-targeted. The test suite is updated consistently: the new test locks in the single task-scoped call, the refactored helper preserves fixture correctness for functions that still use assertSchtasksAvailable(), and the import of schtasksCalls was already exported. The only open item is the P2 robustness note about uncaught spawn errors in the ENOENT edge case, which is an extreme corner case on Windows and does not affect normal operation.
• No files require special attention; the P2 comment on src/daemon/schtasks.ts is a robustness suggestion, not a blocker.

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.

_{Last reviewed commit: "Daemon: query Window..."}

Refreshed this PR onto the current upstream/main.

The runtime path still needs the original fix on main: readScheduledTaskRuntime() was still doing a global schtasks /Query preflight before the task-scoped query, so this refresh keeps the scope narrow:

• query schtasks /Query /TN <taskName> /V /FO LIST directly for runtime reads
• preserve the Startup fallback behavior when that task-scoped query fails or the execSchtasks call itself throws
• lock in the single-call behavior plus the spawn-error fallback with focused regression coverage

Re-verified with focused checks:

• pnpm exec oxfmt --check src/daemon/schtasks.ts src/daemon/schtasks.startup-fallback.test.ts src/daemon/test-helpers/schtasks-base-mocks.ts src/daemon/test-helpers/schtasks-fixtures.ts
• pnpm exec oxlint src/daemon/schtasks.ts src/daemon/schtasks.startup-fallback.test.ts src/daemon/test-helpers/schtasks-base-mocks.ts src/daemon/test-helpers/schtasks-fixtures.ts
• pnpm test -- src/daemon/schtasks.startup-fallback.test.ts