Windows tray autostart Run entry exceeds 260-character limit and does not launch after sign-in

[tulb-git]

Client or integration

OpenCodex dashboard

Area

Installation or packaging

Summary

On Windows, ocx tray install registers the entire PowerShell tray invocation
directly under:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

With a normal user-owned global npm prefix, the generated command was 493
characters. Microsoft documents that Run/RunOnce command lines must be no
longer than 260 characters:

https://learn.microsoft.com/windows/win32/setupapi/run-and-runonce-registry-keys

OpenCodex reports the tray as installed and Windows marks the startup entry
enabled, but the tray does not launch after the next Windows sign-in. The proxy
service starts normally; only the tray process/icon is missing.

Expected: ocx tray install creates a Windows startup registration that
reliably starts the tray at sign-in.

Reproduction

1. Install OpenCodex globally in the standard per-user npm prefix:

   npm install -g @bitkyc08/opencodex@2.7.41

2. Install the tray:

   ocx tray install

3. Inspect the generated HKCU Run value. In this environment it was:

   "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass -WindowStyle Hidden -File "C:\Users\[user]\.opencodex\opencodex-tray.ps1" -BunPath "C:\Users\[user]\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\node_modules\bun\bin\bun.exe" -CliPath "C:\Users\[user]\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\cli\index.ts" -CodexHome "C:\Users\[user]\.codex" -OpenCodexHome "C:\Users\[user]\.opencodex" -Mode Run
   

   Length: 493 characters.

4. Restart Windows and sign in.

5. Observe that the OpenCodex proxy service is healthy, but the tray icon is
   absent and ocx tray status --json reports:

   {"supported":true,"installed":true,"running":false,"stale":false,"summary":"installed, not currently running"}

6. The HKCU Run value still matches tray-state.json, and
   Explorer\StartupApproved\Run contains the enabled value
   020000000000000000000000. No tray PowerShell process exists, and the
   heartbeat is left over from the previous session.

7. Starting the tray manually works, confirming that the tray script itself is
   functional and the failure is specifically login persistence.

Version

opencodex 2.7.41

Operating system

Windows 10 Pro x64, build 19045

Provider and model

Not provider-specific.

Logs or error output

Tray API: installed=true, running=false, stale=false
Run command length: 493
StartupApproved: 020000000000000000000000
Heartbeat PID: no longer running
Matching opencodex-tray.ps1 process count: 0
Proxy /healthz: healthy

Suggested fix / validated mitigation

Register a short owned launcher instead of the full PowerShell command. For
example:

"C:\WINDOWS\System32\wscript.exe" //B //NoLogo "C:\Users\[user]\.opencodex\opencodex-tray.vbs"

This replacement was 94 characters. The VBS launcher invoked the existing
PowerShell command invisibly. After adding launcherPath and the matching short
runCommand to tray-state.json, launching through the actual registered VBS
path produced a fresh heartbeat and ocx tray status --json reported:

{"supported":true,"installed":true,"running":true,"stale":false,"summary":"installed and running"}

The current tray state schema already supports an optional launcherPath, and
the installer contains cleanup logic for an older owned VBS launcher, so this
may be a regression from an earlier launcher-based design.

It would also be useful for the installer/tests to assert that a generated
HKCU Run command does not exceed 260 characters under long Windows user/npm
paths.

Checks

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

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[Wibias]

[shipping-github] Research review

Claim: ocx tray install writes an HKCU Run command longer than Windows' 260-char limit, so the tray never starts at sign-in.
Checked against: dev@be177ea5

Field	Finding
Still an issue on latest development?	yes
Exact issue	buildWindowsTrayRunCommand embeds full PowerShell + Bun/CLI/home paths under HKCU\...\Run; optional launcherPath/VBS cleanup exists but install does not register a short launcher
Fixed on development?	no
Open PR covering this?	none for the 260-char Run limit (open tray PRs #752/#644 are unrelated)
Duplicate of?	none
Security relevance	none — n/a
Priority	high — primary Windows tray autostart path silently fails after reboot
Verdict	Needs fix on development

Evidence: src/tray/windows.ts buildWindowsTrayRunCommand still builds the long PowerShell -File command; install writes that as runCommand. Reporter's short wscript VBS path (~94 chars) matches leftover launcherPath cleanup logic.
Gaps: Did not re-measure Run string length on a live Windows npm-global install in this session.

[Wibias]

[shipping-github] Opened PR #771 to address this.

[lidge-jun]

Fixed on codex/260731-pr-merge-round (13a76a38a, from PR #771).

HKCU Run values are capped at 260 characters, and the tray was registering a full PowerShell invocation carrying the Bun path, the CLI entry, the tray script and both home directories. Under a long Windows profile name that blew the cap, and the entry silently never launched after sign-in.

An owned VBS launcher now holds the long command; the Run value is wscript.exe //B //NoLogo <launcher>. The launcher lives in the config directory, is tracked in tray state, ownership-checked before reuse and rolled back on failure, so a stale or foreign file at that path is not executed.

The regression test builds an entry with a realistically long profile path and asserts the Run value stays under 260 characters, names wscript.exe, and points at the .vbs — plus that the PowerShell form still exceeds 260, which is what gives the first three assertions meaning.

Windows behavior cannot be exercised from macOS, so the matrix CI on the branch is the confirmation; local evidence covers the command-construction functions. The branch merges into dev and ships once the optimization work in flight there lands.