fix(windows): startup safety falsely marks healthy scheduler service stale #432

Client or integration

OpenCodex dashboard

Area

Service lifecycle

Summary

On Windows, a successfully installed and functioning Task Scheduler service is reported as stale by both ocx status and the Dashboard's Startup Safety page.

The generated task XML explicitly contains enabled/default lifecycle fields, but Windows canonicalizes the registered task on export and omits default-valued elements. windowsTaskRegistrationHealthy() currently requires those elements to be present literally, so a healthy task is rejected.

Expected: an enabled, logon-triggered scheduler task using the expected wscript.exe launcher is considered viable even when Windows omits XML elements whose effective values are the expected defaults.

Actual: Restart safety: AT RISK after restart (background service files are stale...) remains after a successful elevated reinstall.

Reproduction

1. Install OpenCodex 2.7.39 on Windows 11.

2. In an elevated PowerShell, run:

   ocx service install
   Start-Sleep 8
   ocx status

3. Installation reports success:

   opencodex service installed + started (auto-starts on login, auto-restarts on crash).
   

4. Status still reports:

   Restart safety: AT RISK after restart (background service files are stale; run 'ocx service install')
   Service: installed, stale or missing service assets
   

5. The generated opencodex-service-task.xml contains:

   <LogonTrigger>
     <Enabled>true</Enabled>
   </LogonTrigger>
   <Principal id="Author">
     <LogonType>InteractiveToken</LogonType>
     <RunLevel>LeastPrivilege</RunLevel>
   </Principal>
   ...
   <Enabled>true</Enabled>

6. The registered task exported by schtasks.exe /query /tn opencodex-proxy /xml is canonicalized to this equivalent form:

   <LogonTrigger />
   <Principal id="Author">
     <UserId>[REDACTED SID]</UserId>
     <LogonType>InteractiveToken</LogonType>
   </Principal>
   <Settings>
     ...
     <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
     <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
     ...
   </Settings>

   The default-valued Enabled=true and RunLevel=LeastPrivilege elements are omitted.

7. Independent task/process checks show the installation is functional:

   • Task is enabled.
   • Trigger is at user logon.
   • Last task result is 0.
   • Expected wscript.exe /b /nologo ...opencodex-service-launcher.vbs action is registered.
   • service-state.json records backend scheduler; its baked Bun and CLI paths exist.
   • Proxy health is OK on port 10100.

Re-running ocx service install reproduces the same result because Task Scheduler exports the same canonicalized XML.

Version

2.7.39

Operating system

Microsoft Windows 11 Pro, version 10.0.26200, x64; PowerShell 7.6.3

Provider and model

Not provider-specific.

Logs or error output

$ ocx health --json
{"ok":true,"pid":[REDACTED],"port":10100}

$ ocx status
Proxy: running
Health: http://127.0.0.1:10100/healthz ok v2.7.39
Restart safety: AT RISK after restart (background service files are stale; run 'ocx service install')
Service: installed, stale or missing service assets

Suggested fix

In windowsTaskRegistrationHealthy(), interpret omitted default-valued fields according to Task Scheduler semantics:

• Missing trigger Enabled => enabled; explicit false => unhealthy.
• Missing settings Enabled => enabled; explicit false => unhealthy.
• Missing RunLevel => LeastPrivilege; explicit non-LeastPrivilege => unhealthy.

Keep the existing exact checks for action path, launcher arguments, logon type, multiple-instance policy, and execution limit.

A regression test using the canonicalized exported XML above would catch this without weakening checks for explicit unsafe values.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.