[cash-flow-king]

Environment	Version / details
OS	Windows 11 Pro, 64-bit
Windows version / build	10.0.26300 / 26300
Architecture	x64
Pi	1.1.0
Node.js	24.14.1
npm	11.12.1
Codex CLI	0.162.1, installed globally through npm
Extension patch baseline	0.13.0 (02a23c0)
Affected clients	Pi TUI and FrostPi GUI, reading the same shared quota state

Problem

The Codex CLI fallback fails to start on Windows when Codex is installed through npm.

Running codex --version in a terminal works, but the extension’s direct spawn("codex", …) fails with:

Failed to start codex app-server: spawn codex ENOENT

The npm installation exposes a codex.cmd shim that the terminal can launch, but the extension’s shell-free launch method does not resolve it to the actual executable.

This became visible when the primary quota endpoint started returning HTTP 401. With the CLI fallback also unavailable, quota refreshes repeatedly failed. The extension retained its last good report for an hour, then displayed error in both clients.

Changes

• Resolve Windows Codex installations to the native codex.exe and launch it directly without a shell.
• Support standalone executables on PATH, current npm optional-package binaries, and older bundled vendor layouts.
• Handle x64 and ARM64 npm installations.
• Preserve normal Codex PATH lookup on non-Windows platforms.
• Hide the helper’s console window on Windows.
• Provide installation and restart instructions when no supported executable is found.
• Add regression coverage for executable resolution, recovery after HTTP 401, startup and RPC errors, timeouts, lost leadership, and actual helper-process termination.
• Document Windows fallback behavior.
• Add Windows and Linux CI validation using Node.js 24.

Launching the native executable directly also keeps process disposal attached to the actual app-server process rather than an intermediate shell or Node wrapper.

Validation

On Windows:

• npm run validate passed.
• All 13 new launcher/fallback tests passed.
• Full suite: 77 passed, 1 platform-specific skip.
• Typecheck, extension import, dependency audit, and package dry-run passed.
• git diff --check passed.
• The resolved native executable successfully reported codex-cli 0.162.1.

Fallback recovery and failure cases use local fixtures and do not require subscription credentials or live quota requests.

Windows/Linux GitHub Actions jobs are configured but have not run yet.

Scope and limitations

This PR fixes Windows CLI fallback startup, not the primary endpoint’s HTTP 401 response. The reason for that access-enforcement rejection remains unconfirmed.

Quota normalization, shared refresh coordination, and Fast behavior are unchanged. The separate Fast-related fork changes are not included.

Assisted by Pi.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-12T20:54:21.388266Z	0907e4c	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[llblab]

Thanks for this — your diagnosis was exactly right. npm installs Codex behind a codex.cmd shim, and a shell-free spawn("codex", …) cannot launch it, so the CLI fallback died with spawn codex ENOENT precisely when the primary quota endpoint started returning HTTP 401. That is a real Windows bug, and this PR is what surfaced it.

A fix is now shipped in v0.13.1 — https://github.com/llblab/pi-codex-usage/releases/tag/v0.13.1 (commit 1bcf725, npm @llblab/pi-codex-usage@0.13.1) — so this PR is superseded, and it now also conflicts with main.

What shipped, compared with this PR:

• lib/query.ts resolves the native codex.exe from PATH or from the npm platform package and launches it directly without a shell, with windowsHide: true. Non-Windows platforms keep plain PATH lookup.
• Package discovery probes the nested (@openai/codex/node_modules/@openai/codex-win32-<arch>) and hoisted (node_modules/@openai/codex-win32-<arch>) locations explicitly instead of using createRequire + require.resolve(.../package.json), so it does not depend on the platform package exposing ./package.json through exports.
• Only the current vendor/<target>/bin/codex.exe layout is handled; the legacy vendor/<target>/codex/ and older bundled layouts are not.
• Added focused resolver tests and a Linux + Windows GitHub Actions matrix; both jobs pass on windows-latest.

So I'm closing this as superseded — not because the approach was wrong, but because the shipped version covers the same failure. If you have hit a layout it misses (for example the older bundled vendor/<target>/codex/codex.exe), a narrow follow-up PR is welcome. Thanks again for the careful report.