[Bug][Windows] ocx service install fails with 'exit code 199' — elevated Register-ScheduledTask launcher script split by '; ' join (no UAC, Start-Process -ArgumentList/-Verb never run)

[browseros247-dev]

Client or integration

CLI — ocx service install on Windows from a non-elevated PowerShell 7 terminal.

Area

Service install / Task Scheduler registration — src/lib/windows-elevation.ts → runWindowsElevatedScheduledTaskRegistration() (the fresh-install elevated fallback used by registerFreshWindowsSchedulerTask() in service.ts).

Summary

On a clean install with no existing opencodex-proxy scheduled task, ocx service install fails immediately with ❌ Service install cleanup failed: Background service install failed with exit code 199. and never shows the UAC prompt. Expected: the elevated fallback should prompt UAC, run Register-ScheduledTask, then publish assets and serve on port 10100.

The failure is a launcher-script bug, not a UAC-denial edge case. runWindowsElevatedScheduledTaskRegistration() builds the elevated PowerShell launcher by joining its array with "; ", which terminates the Start-Process statement right after -FilePath. The resulting script is:

$p = Start-Process -FilePath 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe';  -ArgumentList '-NoProfile ...';  -Verb RunAs -WindowStyle Hidden -PassThru -Wait; if ($null -eq $p) { exit 1223 } ...

So -ArgumentList and -Verb RunAs become standalone statements → two CommandNotFoundException errors, elevation never runs (no UAC), and PowerShell exits with a spurious code (observed 199) that the CLI surfaces verbatim. The adjacent runWindowsElevated() builds the same kind of launcher correctly using join("") with ; terminators embedded on the previous lines.

Reproduction

1. Fresh npm i -g @bitkyc08/opencodex (2.19.0), or ensure no task exists: schtasks /delete /tn opencodex-proxy /f
2. From a non-elevated PowerShell 7: ocx service install
3. Observe: no UAC prompt appears; it prints ❌ Service install cleanup failed: Background service install failed with exit code 199.

I also verified that elevation itself works on this machine: a manual elevated Register-ScheduledTask with the same generated task XML succeeds (exit 0). The malformed launcher script is the only failing piece.

Version

@bitkyc08/opencodex 2.19.0 (latest on npm)

Operating system

Windows 11 24H2 (build 10.0.26200), non-elevated PowerShell 7.5

Provider and model

N/A — not provider-specific

Logs or error output

CLI:

❌ Service install cleanup failed: Background service install failed with exit code 199.

Elevated launcher stderr (captured by instrumenting startPowerShellCommand):

-ArgumentList : The term '-ArgumentList' is not recognized as the name of a cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:92
+ ... stem32\WindowsPowerShell\v1.0\powershell.exe';  -ArgumentList '-NoPro ...
+                                                     ~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (-ArgumentList:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

-Verb : The term '-Verb' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:11070
+ ... aQBvAG4AIABTAHQAbwBwACAAfAAgAE8AdQB0AC0ATgB1AGwAbAA=';  -Verb RunAs - ...
+                                                             ~~~~~
    + CategoryInfo          : ObjectNotFound: (-Verb:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Screenshots and supporting files

n/a

Redacted configuration

None required — no configuration shape is involved.

Suggested fix

In runWindowsElevatedScheduledTaskRegistration(), mirror runWindowsElevated(): move the ; terminators onto the preceding lines and join(""):

const script = [
  `$p = Start-Process -FilePath ${psSingleQuote(windowsPowerShell())}`,
  ` -ArgumentList ${psSingleQuote(buildWindowsElevatedArgumentList([...]))}`,
  " -Verb RunAs -WindowStyle Hidden -PassThru -Wait;",
  `if ($null -eq $p) { exit ${OCX_ELEVATED_UAC_CANCELLED} }`,
  "$null = $p.Handle;",
  `if ($null -eq $p.ExitCode) { exit ${OCX_ELEVATED_PROTOCOL_FAILED} }`,
  "exit $p.ExitCode",
].join("");

With this one-line fix the identical reproduction completes successfully: task \opencodex-proxy registered (ownership nonce), assets published under ~/.opencodex, and the proxy serving on port 10100.

Checks

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

[coderabbitai]

🔗 Related PRs

#408 - fix(service): retry Windows background install with UAC elevation [merged]
#698 - fix(windows): classify localized scheduler denial (#591) [merged]
#868 - fix(windows): settle scheduler registration verification [open]
#1626 - fix(windows): remove native service on fresh scheduler install [open]
#1647 - fix(tray): let the service wrapper exit 0 on an already-live proxy [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[ulrich-zogo]

I’m taking this. I verified that the malformed scheduled-task elevation launcher is still present on current dev. I’ll add a focused regression test around the generated Start-Process command, apply the minimal outer-launcher join fix, and preserve the trusted PowerShell resolution, immutable encoded XML transport, UAC cancellation, and elevated exit-code protocol.

[Ingwannu]

Confirmed against current dev: the outer scheduled-task elevation launcher terminates Start-Process before -ArgumentList and -Verb RunAs, so this is a real fresh-install Windows bug.

PR #1860 contains the correctly scoped fix on current dev. I reviewed its current exact head (6e68c0ebb): it changes only the launcher assembly and one focused regression, preserves the trusted absolute System32 PowerShell path, encoded XML transport, UAC cancellation code, and elevated exit-code protocol, and the focused Windows elevation suite passes locally (52/52).

The PR is still a draft and its full exact-head CI/readiness gate is not complete, so I am not merging it yet. Once the author marks it ready and cross-platform CI is green, it is a strong merge candidate for this issue.

[lidge-jun]

Fixed by #1860 (merge ac8c0d2df) and released in v2.24.0; also present in v2.24.1 and v2.24.2.

The elevated Register-ScheduledTask launcher was being assembled by joining its
parts with "; ", which split the single Start-Process invocation into separate
statements. -ArgumentList and -Verb RunAs were therefore never applied to the
process that actually ran, so no UAC prompt appeared and the install exited 199.
#1860 keeps the launcher as one PowerShell command, so the arguments and the
elevation verb stay attached to the call they belong to.

Verified by ancestry rather than by release notes:

git merge-base --is-ancestor ac8c0d2df v2.24.0  # exit 0

Closing as completed. If ocx service install still fails on a clean install of
v2.24.2 or later, please reopen with the elevation prompt behaviour and the exit
code you see — that would be a different defect in the same path, and it should
not inherit this issue's history.