fix(windows): support long Codex executable paths - #704
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
@codex review |
|
Codex Review: Didn't find any major issues. Bravo. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@codex review Updated to
SDK type checking and changed-file formatting pass. Production code, cancellation assertions, scope/data assertions, and timeouts are unchanged. The initial CI run remains recorded as failed. Its separate failure in the unchanged parallel credential-import test is being investigated independently; this commit does not claim to fix it. Current-head CI is pending. |
|
Codex Review: Didn't find any major issues. Another round soon, please! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Summary
Fix Windows Codex launches from deeply nested installation directories. Node can return
ENOENTfor an existing executable with a long ordinary Windows path; launching the same binary with an extended-length path succeeds.This is a reproduced deep-installation failure, not a claim that normal shallow installations fail or that every path above a single length is affected.
Changes
CODEX_CLI_PATHunchanged; preserve bare, relative, drive-relative, root-relative, and non-Windows lookup semantics.PATHsetup. Explicit overrides retain their existing tool-search behavior, and input environment objects are not mutated.Testing
Local Windows validation, with the existing Codex/SDK
0.149.1pins:--versionlaunches passed across long ordinary, already-namespaced, and shallow paths. The original ordinary long-path failure was reproduced separately with the same binary.PATHpreservation for default selection only. These were not model-backed scans.pnpm pack/prepack, and explicit-contract static archive inspection passed. The archive is a local working-tree validation artifact; installed-package smoke and the full suite were not run locally.An initial comparison run rejected the temporary credential directory's ancestry. The unchanged test file then passed under a verified private test parent without changing ACLs or relaxing credential checks. Initial new-fixture cleanup/termination and quoted-path assertion failures were corrected in the tests before the final passing runs.
Risk and rollout
The default Windows SDK path now uses an explicit executable override, so retaining its bundled-tool search path is essential; both option-level tests and real SDK child observations cover this. Non-Windows default SDK selection is unchanged.
No dependency versions, credentials, sandbox policies, or persistent settings change. UNC conversion has string-level coverage only; network-share execution and a full model-backed scan were not exercised. No release or automatic merge is included.
Public disclosure review