Windows: non-elevated ocx service install fails because LogonTrigger omits UserId — "Access is denied" is a misdiagnosis #4425

Client or integration

Codex CLI

Area

Service lifecycle

Summary

On Windows, a fresh ocx service install from a non-elevated shell fails with

Service install cleanup failed: Windows access denied while running Task Scheduler.
Command: schtasks /create /tn opencodex-proxy /xml <stage>\task.xml
Approve the Windows UAC prompt to install the background service, or run `ocx service install` from an elevated PowerShell window.

The access-denied diagnosis is misleading, and elevation is not the actual cause.

Root cause: buildWindowsTaskXml() emits a <LogonTrigger> with no <UserId>:

<Triggers>
  <LogonTrigger>
    <Enabled>true</Enabled>
  </LogonTrigger>
  <SessionStateChangeTrigger>
    <Enabled>true</Enabled>
    <UserId>{SID}</UserId>
    <StateChange>SessionUnlock</StateChange>
  </SessionStateChangeTrigger>
  ...

Task Scheduler interprets an unscoped logon trigger as "any user's logon", which a non-elevated user is not permitted to register, so schtasks /create returns ERROR: Access is denied. The adjacent SessionStateChangeTrigger in the same template already emits ${sessionUserIdElement} (with the explicit comment at src/service.ts:2305-2311 explaining exactly why the scope must be explicit). <LogonTrigger> simply never uses it.

This is an internal inconsistency, not a privilege limitation. The principal is InteractiveToken + LeastPrivilege (same user, no elevation required by design), and an identical task registers successfully without elevation once <UserId> is present.

Expected: <LogonTrigger><Enabled>true</Enabled><UserId>{SID}</UserId></LogonTrigger> — creation succeeds as a normal user.

Reproduction

Two independent confirmations. All commands were run from a non-elevated PowerShell 7 (7.6.6). No UAC prompt was involved.

1. Minimal A/B on the shipped XML shape. Take the exact trigger block buildWindowsTaskXml() produces, and change only the <LogonTrigger>:

SHIPPED: LogonTrigger WITHOUT UserId   exit=1  ERROR: Access is denied.
FIXED:   LogonTrigger WITH UserId      exit=0  SUCCESS

Everything else — InteractiveToken, LeastPrivilege, the three SessionStateChangeTrigger entries, the wscript.exe action — is byte-identical between the two runs.

2. Full ocx service install on a clean machine (no pre-existing task):

ocx service install

Observed:

Service install cleanup failed: Windows access denied while running Task Scheduler.
Command: schtasks /create /tn opencodex-proxy /xml C:\Users\<user>\AppData\Local\Temp\opencodex-service-stage-<rand>\task.xml
Approve the Windows UAC prompt to install the background service, or run `ocx service install` from an elevated PowerShell window.

ocx service status afterwards:

service not installed (Task Scheduler); OpenCodex proxy is running independently on port 10100.

3. Isolation matrix (all non-elevated, schtasks /create /xml on an isolated probe task name; each run used a Task version="1.4" document otherwise identical to the shipped template):

empty <Triggers>                       exit=0
LogonTrigger, no UserId                exit=1  Access is denied
LogonTrigger, with UserId              exit=0
SessionStateChangeTrigger, no UserId   exit=1  Access is denied
SessionStateChangeTrigger, with UserId exit=0
LogonTrigger(no UserId) + SSCT(with)   exit=1  Access is denied
LogonTrigger(with) + 3x SSCT(with)     exit=0

The failure tracks the missing <UserId> exactly, in both trigger types, and disappears the moment a UserId is present. (The SessionStateChangeTrigger-without-UserId row is also why the in-code comment exists: an unscoped recovery trigger is both rejected here and rejected by the live validator.)

Impact of the failed install: none beyond the missing service. The proxy is unharmed — installFreshWindowsSchedulerSafely() registers before it stops the tracked proxy, so the pre-existing proxy (PID unchanged) kept serving http://127.0.0.1:10100/healthz throughout, and the install rolled back cleanly.

Version

2.52.0

Operating system

Windows 11 Pro Insider Preview, version 10.0.26340, x64; PowerShell 7.6.6

Logs or error output

$ ocx service install
Service install cleanup failed: Windows access denied while running Task Scheduler.
Command: schtasks /create /tn opencodex-proxy /xml C:\Users\<user>\AppData\Local\Temp\opencodex-service-stage-<rand>\task.xml
Approve the Windows UAC prompt to install the background service, or run `ocx service install` from an elevated PowerShell window.

# exit code 1

$ ocx service status
service not installed (Task Scheduler); OpenCodex proxy is running independently on port 10100.
Diagnostics: logs: C:\Users\<user>\.opencodex\service.log

$ curl -s -o NUL -w "%{http_code}" http://127.0.0.1:10100/healthz   # proxy unaffected
200

The same defect is present on main — src/service.ts buildWindowsTaskXml() still emits <LogonTrigger> without <UserId>.

Suggested fix

Reuse the existing scoped-user element for the logon trigger, exactly as the sibling session trigger does:

   <Triggers>
     <LogonTrigger>
       <Enabled>true</Enabled>
+      <UserId>${sessionUserIdElement}</UserId>
     </LogonTrigger>

sessionUserIdElement is already computed a few lines above src/service.ts:2309-2311 and is already treated as a required production value (sessionTriggerUserId = resolvedWindowsTaskSid() at src/service.ts:2382; the validator rejects an unscoped recovery trigger). The logon trigger should consume the same value, so the UserId is present on the real install path and the optional-parameter comment stays accurate.

A regression test that asserts the generated XML contains a <UserId> inside <LogonTrigger> (mirroring the existing session-trigger assertion) would lock this in.

But please check the intent first. If an unscoped "any user logon" trigger is genuinely desired here, then the elevation requirement is intentional and only the error message is wrong — it should not tell the user to approve UAC when the XML is what needs to change. The asymmetry with SessionStateChangeTrigger is why I suspect the former.

Relationship to existing reports

• Windows: bare ocx service on an already-installed service fails with WINDOWS_SCHTASKS_CREATE_ACCESS_DENIED instead of repairing/restarting #2287 (bare ocx service on an already-installed service → access-denied) reports the same symptom but concludes it is expected because schtasks /create /f needs elevation. The A/B above shows a non-elevated create succeeds when <UserId> is present, so that conclusion is the misdiagnosis this report is about; Windows: bare ocx service on an already-installed service fails with WINDOWS_SCHTASKS_CREATE_ACCESS_DENIED instead of repairing/restarting #2287's repair/restart routing request is still valid on its own.
• Windows (non-English locales): fresh ocx service install never triggers the UAC elevated fallback — zh-CN "拒绝访问" access-denied is misclassified because the locale-independent fallback is gated behind /f #4182 and Windows: v2.40.0 still misclassifies a valid scheduler task for non-ASCII account names #3320 both fix the classification of an access-denied result (localized text, elevation fallback). This defect is upstream of classification: the shipped XML is not registrable by a normal user in the first place, so no classifier fix can install it without elevation.

Redacted configuration

{ "version": 2, "backend": null, "note": "fresh install attempt; no scheduler service registered, no prior service-state" }

No credentials, tokens, SIDs, account names, or private paths are included above.

Checks

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