fix(service): retry Windows background install with UAC elevation

[Wibias]

Summary

Fixes the Windows dashboard background service install failure when schtasks /create returns access denied (Zugriff verweigert).

Changes

• Add Windows elevation helpers for access-denied detection and UAC relaunch.
• Improve schtasks error messages with actionable guidance.
• Retry dashboard install-service through an elevated CLI run when access is denied, then verify the scheduler task exists.

Verification

• bun test tests/service.test.ts tests/startup-action-control.test.ts tests/windows-elevation.test.ts
• bun run typecheck

Summary by CodeRabbit

• New Features
  • Added Windows-only UAC elevation and Task Scheduler elevated create/run with rollback, including protocol exit codes and bounded output handling.
  • Added post-install verification for scheduled task registration (task/XML/asset checks) and richer reconciliation status reporting.
  • Improved CLI install error classification by extracting stable markers and preserving user-facing detail.
• Bug Fixes
  • Better handling of localized Task Scheduler access-denied and UAC cancellation (including “indeterminate/blocked” install-state behavior).
  • Safer elevated execution outcomes and rollback when verification fails or reconciliation is stale.
• Tests
  • Expanded Bun coverage for elevation, access-denied detection, scheduler verification/reconciliation, and startup install retry/state transitions.

[lidge-jun]

Reviewed — three blocking findings before this can merge:

1. The UAC retry never triggers for the actual error. windows-elevation.ts:7-9 recognizes "access denied" but windows-elevation.ts:33 rewrites it to "Windows denied access", so startup-action-control.ts:59 tests the rewritten message and returns false. A composition probe confirms retryDetected: false. Use a structured/typed access-denied error rather than matching rendered text.

2. Attacker-influenceable Bun code runs elevated. startup-action-control.ts:21-25 elevates durableBunPath() + the repo/npm TS entrypoint under RunAs. The Bun executable may come from OPENCODEX_BUN_PATH (validated only by file size) and the CLI source lives in a user-writable tree — replacement before UAC approval yields admin-level arbitrary code execution. Elevation should be narrowed to a trusted, immutable helper with TOCTOU-safe inputs.

3. Start-Process -ArgumentList loses argument boundaries. windows-elevation.ts:53-56 passes a PowerShell string array; PowerShell joins with spaces and strips quotes, so paths with spaces (e.g. C:\Users\First Last\...) break and a crafted path can inject Bun CLI options. Microsoft recommends one complete argument string with embedded escaped quotes.

Also: execFileSync with no timeout blocks the event loop during UAC, and the test suite only covers detection/formatting helpers — not the actual elevated-retry path.

Per MAINTAINERS.md this is a security-boundary change requiring explicit security review. Happy to re-review after fixes.

[Wibias]

Ready

[lidge-jun]

🔒 Under maintainer review — detailed feedback incoming

@lidge-jun (maintainer) has this PR in an active review pass. Please do not merge or close
it until the detailed review lands; a full comment with specific file:line findings,
failure modes, and suggested fixes is being prepared.

This PR is not part of the current integration batch. It is held back deliberately —
either because it touches a security boundary that MAINTAINERS.md requires an explicit
security review for, because it needs to be split into reviewable units, or because it needs
a rebase onto changes landing in dev right now.

Heads-up on rebasing: dev is receiving a coordinated integration batch today. If this PR
touches the same files, expect to rebase after that batch lands. The upcoming review comment
will name the exact overlapping paths so you only have to do it once.

No action needed from you until then. Thanks for the contribution and for your patience.

_{Review tracker: devlog/_plan/260725_pr_issue_rework · marker posted by the maintainer review pass}

[lidge-jun]

Thank you for working through the Windows service-install recovery path. I found a security-blocking executable-resolution issue that needs to be fixed before this can merge.

src/lib/windows-elevation.ts:212-213 derives the PowerShell executable passed to UAC RunAs from process.env.SystemRoot. That environment variable is caller-controlled, so a hostile process can point it at an attacker-owned directory containing System32\WindowsPowerShell\v1.0\powershell.exe; this code would then ask Windows to execute that binary with administrator privileges. The same trust rule must cover the schtasks.exe path used around src/lib/windows-elevation.ts:446.

Please resolve the real Windows system directory through a trusted OS mechanism rather than inherited environment state, construct both PowerShell and schtasks.exe from that trusted result, and fail closed if resolution cannot be verified. Add a regression test that launches the resolver with a hostile SystemRoot and proves neither elevated executable comes from it.

Because this code selects binaries for UAC elevation, it is an explicit security boundary under MAINTAINERS.md and requires maintainer security review in addition to the normal CI gates. Thanks again for improving the Windows path; once executable provenance is fixed and tested, the retry behavior can be reviewed on its own merits.

---

_{Reviewed as part of a maintainer integration pass. dev moved to ebc62d1f today (7 PRs integrated); Cross-platform CI is green on ubuntu, macOS, and Windows.}

[Wibias]

Addressed the executable-provenance block:

• powershell.exe and schtasks.exe for UAC elevation now resolve from GetSystemDirectoryW (kernel32), not process.env.SystemRoot / WINDIR.
• Resolution fails closed when the API/load/path verification cannot be trusted.
• Regression test poisons SystemRoot/WINDIR and asserts neither elevated binary comes from that tree.

Commit: c55db9d — still needs maintainer security review per MAINTAINERS.md.

[Wibias]

Ready for merge. @lidge-jun

[lidge-jun]

Follow-up review at head 733c6f23. You've addressed everything from the previous round, and the elevation path is materially safer now — the structured access-denied marker survives the process boundary, the elevated target is narrowed from Bun/TypeScript to trusted system PowerShell and schtasks.exe, both resolve through GetSystemDirectoryW, Start-Process receives one Win32-quoted argument string, blocking execFileSync elevation is gone, and the timeout/cancellation/rollback/hostile-SystemRoot cases have tests. CI is green including the Windows and windows-schtasks jobs.

One blocker remains, and it undermines the install lock rather than the elevation itself.

windowsSchedulerTaskInstalled() collapses every query failure into "absent".

try {
  return querySchtasks(["/query", "/tn", taskName]).includes(taskName);
} catch {
  return false;
}

A permission failure and a genuinely missing task are indistinguishable here. That boolean feeds unknown-protocol and late-timeout reconciliation, so isPartialInstallError() can classify the resulting unknown result as releasable — and a task that may in fact be present releases the install lock, permitting another registration attempt against it.

A tri-state probe fixes this. Query the specific task; on failure, fall back to a CSV listing before concluding absence; if both fail, return unknown with the detail:

export type WindowsSchedulerTaskProbe =
  | { status: "present" }
  | { status: "absent" }
  | { status: "unknown"; detail: string };

Keep windowsSchedulerTaskInstalled() as a thin convenience over probe(...).status === "present", and change the security-sensitive reconciliation paths to consume the probe directly. Any unknown must become blocked-partial, never released. clearStartupInstallPartialBlock() should require an observed probe and clear only on absent.

The regression to add: inject a probeTask hook returning { status: "unknown", detail: "Access is denied…" }, drive a late protocol-failed result, and assert the reconciliation resolves to blocked-partial and that install state is never written. That requires adding probeTask to FinalizeHooks; it fails against the current head because a query failure flattens to absence.

Status: held for explicit security review under MAINTAINERS.md — this is a privilege-elevation path, and green CI does not substitute for that review. The probe fix should land first so the review sees the final shape.

Thank you for the iterations on this one; narrowing the elevated target was the right call and it made the remaining issue much easier to see.

---

_{Reviewed as part of a maintainer PABCD pass. Adds a finding not present in the earlier pass.}

[Wibias]

Ready for merge. @lidge-jun

[Ingwannu]

Explicit maintainer review completed at exact head b711ddf4aabd45f4913f2b2a78add4aa751d9645. The elevated path remains restricted to trusted system PowerShell and schtasks.exe resolved through GetSystemDirectoryW, preserves argument boundaries, and does not elevate Bun or repository code. The remaining install-lock blocker from the prior review is fixed with a tri-state scheduler probe: query failures fall back to an exact CSV lookup, unverifiable state remains unknown, late protocol reconciliation becomes blocked-partial, and the lock clears only on proven absence. Verified 121 focused service/elevation/reconciliation tests plus typecheck; all current cross-platform and dedicated Windows service checks are green.

[Ingwannu]

Maintainer approval is complete at b711ddf4. I also verified the final PR tree is limited to the seven Windows service/elevation source and test files; there is no workflow-file diff. The merge-commit API nevertheless rejects this branch history for the current maintainer OAuth token because it lacks the workflow scope. I am not changing the merge method to bypass that permission boundary. @lidge-jun, please perform the final merge with owner credentials; the exact head, focused tests, typecheck, dedicated Windows jobs, and cross-platform CI are all green.