Detect Codex installs managed by pnpm#31503
Conversation
| { | ||
| "bun": "CODEX_MANAGED_BY_BUN", | ||
| "pnpm": "CODEX_MANAGED_BY_PNPM", | ||
| }[detectPackageManager()] ?? "CODEX_MANAGED_BY_NPM"; |
There was a problem hiding this comment.
@codex is there a better way to do this that's less ugly?
There was a problem hiding this comment.
Hahaha. We can do a nested ternary?
| // pnpm records installation metadata in node_modules/.modules.yaml. Search | ||
| // the canonical package root and lexical entrypoint because either can be |
There was a problem hiding this comment.
@codex i'm a bit worried about this while(true) and traversal through a potentially deepish directory, is there no better way to distinguish pnpm from npm?
There was a problem hiding this comment.
Summary
- Replaced the unbounded
while (true)parent-directory walk in pnpm detection with a bounded scan ofnode_modulesroots derived from the resolved Codex package paths. codex-cli/bin/codex.jsL123-L140 - Kept the pnpm ownership guard intact by requiring
.modules.yamland verifying thatnode_modules/@openai/codexresolves to the current Codex package root before returningpnpm. codex-cli/bin/codex.jsL142-L156 - Committed the follow-up change as
68aa389a314224d0697958b8150ec689b456ea83and created the follow-up PR titled “Bound pnpm owner detection in CLI shim.”
Testing
- ✅
node --check codex-cli/bin/codex.js && prettier --check codex-cli/bin/codex.js && git diff --check ⚠️ cd codex-rs && just fmt(failed due environment/tooling limits: missingdotslash, plus Python formatter dependencies could not be downloaded through the proxy)
| Other, | ||
| } | ||
|
|
||
| enum ManagedPackageManager { |
There was a problem hiding this comment.
Hmm why do we have to introduce a new type here since we already have the InstallContext? Maybe would be better to impl some is_managed method on InstallMethod if that data is needed?
| CODEX_MANAGED_PACKAGE_ROOT: realpathSync(path.join(__dirname, "..")), | ||
| CODEX_MANAGED_PACKAGE_ROOT: codexPackageRoot, | ||
| }; | ||
| delete env.CODEX_MANAGED_BY_NPM; |
There was a problem hiding this comment.
Why do we need to delete the env variables newly?
| ) | ||
| } | ||
|
|
||
| fn from_exe_with_package_manager_and_codex_home( |
There was a problem hiding this comment.
I think if we dont introduce ManagedPackageManager type we might not need the new function/scaffolding here
3 participants
Why
The Codex JavaScript shim currently distinguishes npm and Bun installs, but a global pnpm install falls back to npm. That causes the native CLI,
codex doctor, and update flows to report or run npm commands even though pnpm owns the installation. pnpm also allows its global package and bin directories to differ, soPNPM_HOMEdoes not reliably identify the package owner.What changed
node_modules/.modules.yamlmetadata from the launched JavaScript entrypointCODEX_MANAGED_BY_PNPMmarker into the native CLIInstallContext::from_exesignaturepnpm add -g @openai/codexfor pnpm-managed installs and snapshot the rendered TUI update noticeValidated with the 9-test install-context suite, the focused pnpm TUI snapshot test, and Node's syntax check for the launcher.