Use the native Codex update command for supported versions

[Destreyf]

What Changed

• Use the configured Codex executable with structured ["update"] arguments when the installed version is valid semver and >= 0.128.0 and the installation is npm-, Bun-, Homebrew-, or standalone-managed. Default installations continue to execute codex update, while custom names and absolute paths update the same executable that was probed.
• Retain the existing npm, pnpm, Bun, Vite+, and Homebrew path detection for older, missing, or malformed versions. pnpm and Vite+ retain their legacy commands at every version because upstream native detection currently classifies their JS wrappers as npm-managed.
• Store the resolved maintenance capability with each provider snapshot so versionAdvisory.updateCommand, canUpdate, and runner execution stay aligned.
• Preserve package-manager lock grouping for native updates and reserve the Codex-native lock for standalone or otherwise unclassified installations.
• Preserve the configured provider-instance environment and effective home for native updates. Standalone executables override auth-overlay shadow homes with the shared installation home derived from the already-resolved path.
• Add strict semver validation and focused coverage for the stable boundary, prereleases, legacy managers, manual-only paths, configured executables, install context, and update concurrency.

Why

Codex added its native codex update command in openai/codex@b985768. It first appeared in 0.126.0-alpha.9, but 0.128.0 was the first stable npm release containing it, so this uses 0.128.0 as the conservative capability boundary.

Supported modern Codex installations can therefore perform their own installation-method detection instead of relying on T3 Code to invoke a package manager. Older or indeterminate installations, plus pnpm and Vite+ installations not currently supported by the native detector, continue using the existing behavior. Other provider drivers are unchanged.

Fixes#4066.

Related: #2765 covers Windows-specific child-process/PATH failures when spawning package-manager update commands. This PR may avoid that path for supported modern Codex installations, but it does not replace the Windows-specific fix.

Testing

• Focused provider-maintenance suite — 98 passed
• Provider-instance, adapter-registry, and Codex-home integration suite — 11 passed
• vp check — passed with 9 existing unrelated web lint warnings
• vp run typecheck — passed

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (no animation or interaction changes)

Note

Use native codex update command for Codex versions >= 0.128.0

• Introduces version-gated maintenance capability selection in codexMaintenance.ts: versions >= 0.128.0 use the native codex update command; older versions retain legacy package-manager (pnpm/vp) updates.
• Adds makeCodexMaintenanceEnvironment to set CODEX_HOME based on whether the executable is from a shared standalone install or an instance-specific path.
• Changes ServerProviderShape.maintenanceCapabilities from a synchronous property to getMaintenanceCapabilities, an Effect, allowing capabilities to update when the probed version changes.
• Extends ProviderMaintenanceCommandAction with an optional env field; ProviderMaintenanceRunner now passes this env (e.g. CODEX_HOME) to spawned update processes.
• Fixes parseSemver in both shared/src/semver.ts and providerMaintenance.ts to strip build metadata before parsing numeric segments.
• Behavioral Change: consumers of ServerProviderShape must now call getMaintenanceCapabilities as an Effect instead of reading a direct property.

^{Macroscope summarized 90b261b.}

---

Note

Medium Risk
Changes provider self-update execution (spawn env, version-gated commands) and makes maintenance capabilities async per snapshot; mistakes could run wrong update commands or misreport update availability for Codex.

Overview
Codex provider updates now prefer the probed executable’s native codex update flow when the installed version is valid semver and ≥ 0.128.0; older, missing, or malformed versions keep the existing package-manager path detection (with pnpm and vp always on legacy commands).

Maintenance capabilities are tied to the live snapshot:ServerProviderShape exposes getMaintenanceCapabilities as an Effect instead of a fixed field, and makeManagedServerProvider can resolveMaintenanceCapabilities after each probe so version advisories, canUpdate, and the update runner use the same command. Codex wires this through new codexMaintenance helpers (version gate, optional update env including CODEX_HOME for standalone installs) and resolveProviderMaintenanceCapabilitiesWithPathsEffect for resolved binary paths.

The maintenance runner forwards optional env into child-process spawn; shared semver gains isValidSemverVersion and build-metadata stripping in parseSemver.

^{Reviewed by Cursor Bugbot for commit e0ae1d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces version-gated maintenance capabilities that change how Codex updates are executed based on installed version. It adds new selection logic, interface changes (sync to Effect-based), and environment handling - significant runtime behavior changes that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 262ea88d-b6e4-40de-bf67-2246c27dca6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NicL9923]

Three install-context and update-coordination issues below. The capability/snapshot state plumbing and validation otherwise look solid.

[Dropje97]

Just added a second, independent reproduction of the underlying bug in #5629 — same standalone-installer layout, but with npm's global prefix set to ~/.local, the npm install -g fallback collides with the installer's own symlink and exits 1 (EEXIST) instead of silently installing a shadow copy. So on that configuration the in-app update isn't just cosmetically stuck, it fails outright with no path forward from the UI.

Mentioning it here mostly as a data point that the nativeUpdate path this PR adds fixes more than the "still needs an update" loop.

@Destreyf — this is currently conflicting against main and has been idle since late July. Any appetite to rebase it? Happy to test a rebased branch against a standalone install on Linux if that helps.

[Destreyf]

@Dropje97 should be rebased appropriately now.

[Dropje97]

Tested e0ae1d7 on Linux against a standalone install.

~/.local/bin/codex -> ~/.codex/packages/standalone/releases/0.151.0-x86_64-unknown-linux-musl/bin/codex
codex-cli 0.151.0, binaryPath left at the default "codex", CODEX_HOME unset

Before this PR the advisory resolves to the npm command, which exits 1 on this machine — my npm global prefix is ~/.local, the same bin dir the standalone installer owns, so npm's bin-link step hits EEXIST (this is #5629). Straight out of the provider cache on my running instance:

"status": "behind_latest", "currentVersion": "0.151.0", "latestVersion": "0.152.0",
"updateCommand": "npm install -g --allow-scripts=@openai/codex @openai/codex@latest"

With this PR, driving the real resolution code against my actual filesystem and the running server's PATH:

resolvedCommandPath = ~/.local/bin/codex
realCommandPath = ~/.codex/packages/standalone/releases/0.151.0-.../bin/codex
legacy = npm install -g --allow-scripts=@openai/codex @openai/codex@latest
selected = codex ["update"], lockKey "npm-global", CODEX_HOME=~/.codex
advisory = updateCommand "codex update", canUpdate true

The version gate lets 0.151.0 through, the standalone CODEX_HOME override fires, and the UI would show the native command instead of the broken npm one.

Test runs on the rebased branch: apps/server/src/provider 740 passed / 8 skipped / 0 failed, packages/shared/src/semver.test.ts 12 passed. Rebase looks clean from here — merge-base is exactly current main, no drift.

Two minor observations, neither a blocker:

1. This standalone install inherits lockKey: "npm-global" rather than codex-native, because the legacy layer classifies a bare binaryPath as npm. It over-serializes, so it is safe, and it looks deliberate and test-covered — just noting it reads differently from the literal wording of the earlier review point about lock grouping.
2. A standalone install located outside the configured home would not get the CODEX_HOME override, and would presumably be classified as "Other" by upstream's own detection. Not a regression, but uncovered. I am less confident about this one — I could not exercise that layout here.

Update — the native command was run end to end, and it works.

I ran it exactly as the runner would spawn it:

$ CODEX_HOME=~/.codex codex update
Updating Codex via `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh'`...
==> Updating Codex CLI from 0.151.0 to 0.152.0
==> Detected platform: Linux (x64)
==> Installing standalone package to ~/.codex/packages/standalone/releases/0.152.0-x86_64-unknown-linux-musl
==> ~/.local/bin is already on PATH
Codex CLI 0.152.0 installed successfully.
exit 0

Post-conditions checked:

• codex --version → codex-cli 0.152.0 (was 0.151.0)
• ~/.codex/packages/standalone/current correctly repointed to releases/0.152.0-..., symlink chain via ~/.local/bin/codex intact
• no npm copy created — ~/.local/lib/node_modules/ still contains no @openai/codex

That last point is the whole difference. Upstream's own install-context detection correctly identified the standalone layout and updated in place, where the legacy npm path either aborts with EEXIST (my prefix) or silently creates a second, unused install (the #5629 reporter's prefix).

So on this configuration the PR takes the provider from "update is impossible from the UI" to "update succeeds", verified end to end.

[Destreyf]

What Changed

• Use the configured Codex executable with structured ["update"] arguments when the installed version is valid semver and >= 0.128.0 and the installation is npm-, Bun-, Homebrew-, or standalone-managed. Default installations continue to execute codex update, while custom names and absolute paths update the same executable that was probed.
• Retain the existing npm, pnpm, Bun, Vite+, and Homebrew path detection for older, missing, or malformed versions. pnpm and Vite+ retain their legacy commands at every version because upstream native detection currently classifies their JS wrappers as npm-managed.
• Store the resolved maintenance capability with each provider snapshot so versionAdvisory.updateCommand, canUpdate, and runner execution stay aligned.
• Preserve package-manager lock grouping for native updates and reserve the Codex-native lock for standalone or otherwise unclassified installations.
• Preserve the configured provider-instance environment and effective home for native updates. Standalone executables override auth-overlay shadow homes with the shared installation home derived from the already-resolved path.
• Add strict semver validation and focused coverage for the stable boundary, prereleases, legacy managers, manual-only paths, configured executables, install context, and update concurrency.

Why

Codex added its native codex update command in openai/codex@b985768. It first appeared in 0.126.0-alpha.9, but 0.128.0 was the first stable npm release containing it, so this uses 0.128.0 as the conservative capability boundary.

Supported modern Codex installations can therefore perform their own installation-method detection instead of relying on T3 Code to invoke a package manager. Older or indeterminate installations, plus pnpm and Vite+ installations not currently supported by the native detector, continue using the existing behavior. Other provider drivers are unchanged.

Fixes#4066.

Related: #2765 covers Windows-specific child-process/PATH failures when spawning package-manager update commands. This PR may avoid that path for supported modern Codex installations, but it does not replace the Windows-specific fix.

Testing

• Focused provider-maintenance suite — 98 passed
• Provider-instance, adapter-registry, and Codex-home integration suite — 11 passed
• vp check — passed with 9 existing unrelated web lint warnings
• vp run typecheck — passed

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (no animation or interaction changes)

Note

Use native codex update command for Codex versions >= 0.128.0

• Introduces version-gated maintenance capability selection in codexMaintenance.ts: versions >= 0.128.0 use the native codex update command; older versions retain legacy package-manager (pnpm/vp) updates.
• Adds makeCodexMaintenanceEnvironment to set CODEX_HOME based on whether the executable is from a shared standalone install or an instance-specific path.
• Changes ServerProviderShape.maintenanceCapabilities from a synchronous property to getMaintenanceCapabilities, an Effect, allowing capabilities to update when the probed version changes.
• Extends ProviderMaintenanceCommandAction with an optional env field; ProviderMaintenanceRunner now passes this env (e.g. CODEX_HOME) to spawned update processes.
• Fixes parseSemver in both shared/src/semver.ts and providerMaintenance.ts to strip build metadata before parsing numeric segments.
• Behavioral Change: consumers of ServerProviderShape must now call getMaintenanceCapabilities as an Effect instead of reading a direct property.

^{Macroscope summarized 90b261b.}

---

Note

Medium Risk
Changes provider self-update execution (spawn env, version-gated commands) and makes maintenance capabilities async per snapshot; mistakes could run wrong update commands or misreport update availability for Codex.

Overview
Codex provider updates now prefer the probed executable’s native codex update flow when the installed version is valid semver and ≥ 0.128.0; older, missing, or malformed versions keep the existing package-manager path detection (with pnpm and vp always on legacy commands).

Maintenance capabilities are tied to the live snapshot:ServerProviderShape exposes getMaintenanceCapabilities as an Effect instead of a fixed field, and makeManagedServerProvider can resolveMaintenanceCapabilities after each probe so version advisories, canUpdate, and the update runner use the same command. Codex wires this through new codexMaintenance helpers (version gate, optional update env including CODEX_HOME for standalone installs) and resolveProviderMaintenanceCapabilitiesWithPathsEffect for resolved binary paths.

The maintenance runner forwards optional env into child-process spawn; shared semver gains isValidSemverVersion and build-metadata stripping in parseSemver.

^{Reviewed by Cursor Bugbot for commit e0ae1d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces version-gated maintenance capabilities that change how Codex updates are executed based on installed version. It adds new selection logic, interface changes (sync to Effect-based), and environment handling - significant runtime behavior changes that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 262ea88d-b6e4-40de-bf67-2246c27dca6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NicL9923]

Three install-context and update-coordination issues below. The capability/snapshot state plumbing and validation otherwise look solid.

[Dropje97]

Just added a second, independent reproduction of the underlying bug in #5629 — same standalone-installer layout, but with npm's global prefix set to ~/.local, the npm install -g fallback collides with the installer's own symlink and exits 1 (EEXIST) instead of silently installing a shadow copy. So on that configuration the in-app update isn't just cosmetically stuck, it fails outright with no path forward from the UI.

Mentioning it here mostly as a data point that the nativeUpdate path this PR adds fixes more than the "still needs an update" loop.

@Destreyf — this is currently conflicting against main and has been idle since late July. Any appetite to rebase it? Happy to test a rebased branch against a standalone install on Linux if that helps.

[Destreyf]

@Dropje97 should be rebased appropriately now.

[Dropje97]

Tested e0ae1d7 on Linux against a standalone install.

~/.local/bin/codex -> ~/.codex/packages/standalone/releases/0.151.0-x86_64-unknown-linux-musl/bin/codex
codex-cli 0.151.0, binaryPath left at the default "codex", CODEX_HOME unset

Before this PR the advisory resolves to the npm command, which exits 1 on this machine — my npm global prefix is ~/.local, the same bin dir the standalone installer owns, so npm's bin-link step hits EEXIST (this is #5629). Straight out of the provider cache on my running instance:

"status": "behind_latest", "currentVersion": "0.151.0", "latestVersion": "0.152.0",
"updateCommand": "npm install -g --allow-scripts=@openai/codex @openai/codex@latest"

With this PR, driving the real resolution code against my actual filesystem and the running server's PATH:

resolvedCommandPath = ~/.local/bin/codex
realCommandPath = ~/.codex/packages/standalone/releases/0.151.0-.../bin/codex
legacy = npm install -g --allow-scripts=@openai/codex @openai/codex@latest
selected = codex ["update"], lockKey "npm-global", CODEX_HOME=~/.codex
advisory = updateCommand "codex update", canUpdate true

The version gate lets 0.151.0 through, the standalone CODEX_HOME override fires, and the UI would show the native command instead of the broken npm one.

Test runs on the rebased branch: apps/server/src/provider 740 passed / 8 skipped / 0 failed, packages/shared/src/semver.test.ts 12 passed. Rebase looks clean from here — merge-base is exactly current main, no drift.

Two minor observations, neither a blocker:

1. This standalone install inherits lockKey: "npm-global" rather than codex-native, because the legacy layer classifies a bare binaryPath as npm. It over-serializes, so it is safe, and it looks deliberate and test-covered — just noting it reads differently from the literal wording of the earlier review point about lock grouping.
2. A standalone install located outside the configured home would not get the CODEX_HOME override, and would presumably be classified as "Other" by upstream's own detection. Not a regression, but uncovered. I am less confident about this one — I could not exercise that layout here.

Update — the native command was run end to end, and it works.

I ran it exactly as the runner would spawn it:

$ CODEX_HOME=~/.codex codex update
Updating Codex via `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh'`...
==> Updating Codex CLI from 0.151.0 to 0.152.0
==> Detected platform: Linux (x64)
==> Installing standalone package to ~/.codex/packages/standalone/releases/0.152.0-x86_64-unknown-linux-musl
==> ~/.local/bin is already on PATH
Codex CLI 0.152.0 installed successfully.
exit 0

Post-conditions checked:

• codex --version → codex-cli 0.152.0 (was 0.151.0)
• ~/.codex/packages/standalone/current correctly repointed to releases/0.152.0-..., symlink chain via ~/.local/bin/codex intact
• no npm copy created — ~/.local/lib/node_modules/ still contains no @openai/codex

That last point is the whole difference. Upstream's own install-context detection correctly identified the standalone layout and updated in place, where the legacy npm path either aborts with EEXIST (my prefix) or silently creates a second, unused install (the #5629 reporter's prefix).

So on this configuration the PR takes the provider from "update is impossible from the UI" to "update succeeds", verified end to end.

[Destreyf]

What Changed

• Use the configured Codex executable with structured ["update"] arguments when the installed version is valid semver and >= 0.128.0 and the installation is npm-, Bun-, Homebrew-, or standalone-managed. Default installations continue to execute codex update, while custom names and absolute paths update the same executable that was probed.
• Retain the existing npm, pnpm, Bun, Vite+, and Homebrew path detection for older, missing, or malformed versions. pnpm and Vite+ retain their legacy commands at every version because upstream native detection currently classifies their JS wrappers as npm-managed.
• Store the resolved maintenance capability with each provider snapshot so versionAdvisory.updateCommand, canUpdate, and runner execution stay aligned.
• Preserve package-manager lock grouping for native updates and reserve the Codex-native lock for standalone or otherwise unclassified installations.
• Preserve the configured provider-instance environment and effective home for native updates. Standalone executables override auth-overlay shadow homes with the shared installation home derived from the already-resolved path.
• Add strict semver validation and focused coverage for the stable boundary, prereleases, legacy managers, manual-only paths, configured executables, install context, and update concurrency.

Why

Codex added its native codex update command in openai/codex@b985768. It first appeared in 0.126.0-alpha.9, but 0.128.0 was the first stable npm release containing it, so this uses 0.128.0 as the conservative capability boundary.

Supported modern Codex installations can therefore perform their own installation-method detection instead of relying on T3 Code to invoke a package manager. Older or indeterminate installations, plus pnpm and Vite+ installations not currently supported by the native detector, continue using the existing behavior. Other provider drivers are unchanged.

Fixes#4066.

Related: #2765 covers Windows-specific child-process/PATH failures when spawning package-manager update commands. This PR may avoid that path for supported modern Codex installations, but it does not replace the Windows-specific fix.

Testing

• Focused provider-maintenance suite — 98 passed
• Provider-instance, adapter-registry, and Codex-home integration suite — 11 passed
• vp check — passed with 9 existing unrelated web lint warnings
• vp run typecheck — passed

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (no animation or interaction changes)

Note

Use native codex update command for Codex versions >= 0.128.0

• Introduces version-gated maintenance capability selection in codexMaintenance.ts: versions >= 0.128.0 use the native codex update command; older versions retain legacy package-manager (pnpm/vp) updates.
• Adds makeCodexMaintenanceEnvironment to set CODEX_HOME based on whether the executable is from a shared standalone install or an instance-specific path.
• Changes ServerProviderShape.maintenanceCapabilities from a synchronous property to getMaintenanceCapabilities, an Effect, allowing capabilities to update when the probed version changes.
• Extends ProviderMaintenanceCommandAction with an optional env field; ProviderMaintenanceRunner now passes this env (e.g. CODEX_HOME) to spawned update processes.
• Fixes parseSemver in both shared/src/semver.ts and providerMaintenance.ts to strip build metadata before parsing numeric segments.
• Behavioral Change: consumers of ServerProviderShape must now call getMaintenanceCapabilities as an Effect instead of reading a direct property.

^{Macroscope summarized 90b261b.}

---

Note

Medium Risk
Changes provider self-update execution (spawn env, version-gated commands) and makes maintenance capabilities async per snapshot; mistakes could run wrong update commands or misreport update availability for Codex.

Overview
Codex provider updates now prefer the probed executable’s native codex update flow when the installed version is valid semver and ≥ 0.128.0; older, missing, or malformed versions keep the existing package-manager path detection (with pnpm and vp always on legacy commands).

Maintenance capabilities are tied to the live snapshot:ServerProviderShape exposes getMaintenanceCapabilities as an Effect instead of a fixed field, and makeManagedServerProvider can resolveMaintenanceCapabilities after each probe so version advisories, canUpdate, and the update runner use the same command. Codex wires this through new codexMaintenance helpers (version gate, optional update env including CODEX_HOME for standalone installs) and resolveProviderMaintenanceCapabilitiesWithPathsEffect for resolved binary paths.

The maintenance runner forwards optional env into child-process spawn; shared semver gains isValidSemverVersion and build-metadata stripping in parseSemver.

^{Reviewed by Cursor Bugbot for commit e0ae1d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces version-gated maintenance capabilities that change how Codex updates are executed based on installed version. It adds new selection logic, interface changes (sync to Effect-based), and environment handling - significant runtime behavior changes that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 262ea88d-b6e4-40de-bf67-2246c27dca6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NicL9923]

Three install-context and update-coordination issues below. The capability/snapshot state plumbing and validation otherwise look solid.

[Dropje97]

Just added a second, independent reproduction of the underlying bug in #5629 — same standalone-installer layout, but with npm's global prefix set to ~/.local, the npm install -g fallback collides with the installer's own symlink and exits 1 (EEXIST) instead of silently installing a shadow copy. So on that configuration the in-app update isn't just cosmetically stuck, it fails outright with no path forward from the UI.

Mentioning it here mostly as a data point that the nativeUpdate path this PR adds fixes more than the "still needs an update" loop.

@Destreyf — this is currently conflicting against main and has been idle since late July. Any appetite to rebase it? Happy to test a rebased branch against a standalone install on Linux if that helps.

[Destreyf]

@Dropje97 should be rebased appropriately now.

[Dropje97]

Tested e0ae1d7 on Linux against a standalone install.

~/.local/bin/codex -> ~/.codex/packages/standalone/releases/0.151.0-x86_64-unknown-linux-musl/bin/codex
codex-cli 0.151.0, binaryPath left at the default "codex", CODEX_HOME unset

Before this PR the advisory resolves to the npm command, which exits 1 on this machine — my npm global prefix is ~/.local, the same bin dir the standalone installer owns, so npm's bin-link step hits EEXIST (this is #5629). Straight out of the provider cache on my running instance:

"status": "behind_latest", "currentVersion": "0.151.0", "latestVersion": "0.152.0",
"updateCommand": "npm install -g --allow-scripts=@openai/codex @openai/codex@latest"

With this PR, driving the real resolution code against my actual filesystem and the running server's PATH:

resolvedCommandPath = ~/.local/bin/codex
realCommandPath = ~/.codex/packages/standalone/releases/0.151.0-.../bin/codex
legacy = npm install -g --allow-scripts=@openai/codex @openai/codex@latest
selected = codex ["update"], lockKey "npm-global", CODEX_HOME=~/.codex
advisory = updateCommand "codex update", canUpdate true

The version gate lets 0.151.0 through, the standalone CODEX_HOME override fires, and the UI would show the native command instead of the broken npm one.

Test runs on the rebased branch: apps/server/src/provider 740 passed / 8 skipped / 0 failed, packages/shared/src/semver.test.ts 12 passed. Rebase looks clean from here — merge-base is exactly current main, no drift.

Two minor observations, neither a blocker:

1. This standalone install inherits lockKey: "npm-global" rather than codex-native, because the legacy layer classifies a bare binaryPath as npm. It over-serializes, so it is safe, and it looks deliberate and test-covered — just noting it reads differently from the literal wording of the earlier review point about lock grouping.
2. A standalone install located outside the configured home would not get the CODEX_HOME override, and would presumably be classified as "Other" by upstream's own detection. Not a regression, but uncovered. I am less confident about this one — I could not exercise that layout here.

Update — the native command was run end to end, and it works.

I ran it exactly as the runner would spawn it:

$ CODEX_HOME=~/.codex codex update
Updating Codex via `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh'`...
==> Updating Codex CLI from 0.151.0 to 0.152.0
==> Detected platform: Linux (x64)
==> Installing standalone package to ~/.codex/packages/standalone/releases/0.152.0-x86_64-unknown-linux-musl
==> ~/.local/bin is already on PATH
Codex CLI 0.152.0 installed successfully.
exit 0

Post-conditions checked:

• codex --version → codex-cli 0.152.0 (was 0.151.0)
• ~/.codex/packages/standalone/current correctly repointed to releases/0.152.0-..., symlink chain via ~/.local/bin/codex intact
• no npm copy created — ~/.local/lib/node_modules/ still contains no @openai/codex

That last point is the whole difference. Upstream's own install-context detection correctly identified the standalone layout and updated in place, where the legacy npm path either aborts with EEXIST (my prefix) or silently creates a second, unused install (the #5629 reporter's prefix).

So on this configuration the PR takes the provider from "update is impossible from the UI" to "update succeeds", verified end to end.

[Destreyf]

What Changed

• Use the configured Codex executable with structured ["update"] arguments when the installed version is valid semver and >= 0.128.0 and the installation is npm-, Bun-, Homebrew-, or standalone-managed. Default installations continue to execute codex update, while custom names and absolute paths update the same executable that was probed.
• Retain the existing npm, pnpm, Bun, Vite+, and Homebrew path detection for older, missing, or malformed versions. pnpm and Vite+ retain their legacy commands at every version because upstream native detection currently classifies their JS wrappers as npm-managed.
• Store the resolved maintenance capability with each provider snapshot so versionAdvisory.updateCommand, canUpdate, and runner execution stay aligned.
• Preserve package-manager lock grouping for native updates and reserve the Codex-native lock for standalone or otherwise unclassified installations.
• Preserve the configured provider-instance environment and effective home for native updates. Standalone executables override auth-overlay shadow homes with the shared installation home derived from the already-resolved path.
• Add strict semver validation and focused coverage for the stable boundary, prereleases, legacy managers, manual-only paths, configured executables, install context, and update concurrency.

Why

Codex added its native codex update command in openai/codex@b985768. It first appeared in 0.126.0-alpha.9, but 0.128.0 was the first stable npm release containing it, so this uses 0.128.0 as the conservative capability boundary.

Supported modern Codex installations can therefore perform their own installation-method detection instead of relying on T3 Code to invoke a package manager. Older or indeterminate installations, plus pnpm and Vite+ installations not currently supported by the native detector, continue using the existing behavior. Other provider drivers are unchanged.

Fixes#4066.

Related: #2765 covers Windows-specific child-process/PATH failures when spawning package-manager update commands. This PR may avoid that path for supported modern Codex installations, but it does not replace the Windows-specific fix.

Testing

• Focused provider-maintenance suite — 98 passed
• Provider-instance, adapter-registry, and Codex-home integration suite — 11 passed
• vp check — passed with 9 existing unrelated web lint warnings
• vp run typecheck — passed

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (no animation or interaction changes)

Note

Use native codex update command for Codex versions >= 0.128.0

• Introduces version-gated maintenance capability selection in codexMaintenance.ts: versions >= 0.128.0 use the native codex update command; older versions retain legacy package-manager (pnpm/vp) updates.
• Adds makeCodexMaintenanceEnvironment to set CODEX_HOME based on whether the executable is from a shared standalone install or an instance-specific path.
• Changes ServerProviderShape.maintenanceCapabilities from a synchronous property to getMaintenanceCapabilities, an Effect, allowing capabilities to update when the probed version changes.
• Extends ProviderMaintenanceCommandAction with an optional env field; ProviderMaintenanceRunner now passes this env (e.g. CODEX_HOME) to spawned update processes.
• Fixes parseSemver in both shared/src/semver.ts and providerMaintenance.ts to strip build metadata before parsing numeric segments.
• Behavioral Change: consumers of ServerProviderShape must now call getMaintenanceCapabilities as an Effect instead of reading a direct property.

^{Macroscope summarized 90b261b.}

---

Note

Medium Risk
Changes provider self-update execution (spawn env, version-gated commands) and makes maintenance capabilities async per snapshot; mistakes could run wrong update commands or misreport update availability for Codex.

Overview
Codex provider updates now prefer the probed executable’s native codex update flow when the installed version is valid semver and ≥ 0.128.0; older, missing, or malformed versions keep the existing package-manager path detection (with pnpm and vp always on legacy commands).

Maintenance capabilities are tied to the live snapshot:ServerProviderShape exposes getMaintenanceCapabilities as an Effect instead of a fixed field, and makeManagedServerProvider can resolveMaintenanceCapabilities after each probe so version advisories, canUpdate, and the update runner use the same command. Codex wires this through new codexMaintenance helpers (version gate, optional update env including CODEX_HOME for standalone installs) and resolveProviderMaintenanceCapabilitiesWithPathsEffect for resolved binary paths.

The maintenance runner forwards optional env into child-process spawn; shared semver gains isValidSemverVersion and build-metadata stripping in parseSemver.

^{Reviewed by Cursor Bugbot for commit e0ae1d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces version-gated maintenance capabilities that change how Codex updates are executed based on installed version. It adds new selection logic, interface changes (sync to Effect-based), and environment handling - significant runtime behavior changes that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 262ea88d-b6e4-40de-bf67-2246c27dca6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NicL9923]

Three install-context and update-coordination issues below. The capability/snapshot state plumbing and validation otherwise look solid.

[Dropje97]

Just added a second, independent reproduction of the underlying bug in #5629 — same standalone-installer layout, but with npm's global prefix set to ~/.local, the npm install -g fallback collides with the installer's own symlink and exits 1 (EEXIST) instead of silently installing a shadow copy. So on that configuration the in-app update isn't just cosmetically stuck, it fails outright with no path forward from the UI.

Mentioning it here mostly as a data point that the nativeUpdate path this PR adds fixes more than the "still needs an update" loop.

@Destreyf — this is currently conflicting against main and has been idle since late July. Any appetite to rebase it? Happy to test a rebased branch against a standalone install on Linux if that helps.

[Destreyf]

@Dropje97 should be rebased appropriately now.

[Dropje97]

Tested e0ae1d7 on Linux against a standalone install.

~/.local/bin/codex -> ~/.codex/packages/standalone/releases/0.151.0-x86_64-unknown-linux-musl/bin/codex
codex-cli 0.151.0, binaryPath left at the default "codex", CODEX_HOME unset

Before this PR the advisory resolves to the npm command, which exits 1 on this machine — my npm global prefix is ~/.local, the same bin dir the standalone installer owns, so npm's bin-link step hits EEXIST (this is #5629). Straight out of the provider cache on my running instance:

"status": "behind_latest", "currentVersion": "0.151.0", "latestVersion": "0.152.0",
"updateCommand": "npm install -g --allow-scripts=@openai/codex @openai/codex@latest"

With this PR, driving the real resolution code against my actual filesystem and the running server's PATH:

resolvedCommandPath = ~/.local/bin/codex
realCommandPath = ~/.codex/packages/standalone/releases/0.151.0-.../bin/codex
legacy = npm install -g --allow-scripts=@openai/codex @openai/codex@latest
selected = codex ["update"], lockKey "npm-global", CODEX_HOME=~/.codex
advisory = updateCommand "codex update", canUpdate true

The version gate lets 0.151.0 through, the standalone CODEX_HOME override fires, and the UI would show the native command instead of the broken npm one.

Test runs on the rebased branch: apps/server/src/provider 740 passed / 8 skipped / 0 failed, packages/shared/src/semver.test.ts 12 passed. Rebase looks clean from here — merge-base is exactly current main, no drift.

Two minor observations, neither a blocker:

1. This standalone install inherits lockKey: "npm-global" rather than codex-native, because the legacy layer classifies a bare binaryPath as npm. It over-serializes, so it is safe, and it looks deliberate and test-covered — just noting it reads differently from the literal wording of the earlier review point about lock grouping.
2. A standalone install located outside the configured home would not get the CODEX_HOME override, and would presumably be classified as "Other" by upstream's own detection. Not a regression, but uncovered. I am less confident about this one — I could not exercise that layout here.

Update — the native command was run end to end, and it works.

I ran it exactly as the runner would spawn it:

$ CODEX_HOME=~/.codex codex update
Updating Codex via `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh'`...
==> Updating Codex CLI from 0.151.0 to 0.152.0
==> Detected platform: Linux (x64)
==> Installing standalone package to ~/.codex/packages/standalone/releases/0.152.0-x86_64-unknown-linux-musl
==> ~/.local/bin is already on PATH
Codex CLI 0.152.0 installed successfully.
exit 0

Post-conditions checked:

• codex --version → codex-cli 0.152.0 (was 0.151.0)
• ~/.codex/packages/standalone/current correctly repointed to releases/0.152.0-..., symlink chain via ~/.local/bin/codex intact
• no npm copy created — ~/.local/lib/node_modules/ still contains no @openai/codex

That last point is the whole difference. Upstream's own install-context detection correctly identified the standalone layout and updated in place, where the legacy npm path either aborts with EEXIST (my prefix) or silently creates a second, unused install (the #5629 reporter's prefix).

So on this configuration the PR takes the provider from "update is impossible from the UI" to "update succeeds", verified end to end.

[Destreyf]

What Changed

• Use the configured Codex executable with structured ["update"] arguments when the installed version is valid semver and >= 0.128.0 and the installation is npm-, Bun-, Homebrew-, or standalone-managed. Default installations continue to execute codex update, while custom names and absolute paths update the same executable that was probed.
• Retain the existing npm, pnpm, Bun, Vite+, and Homebrew path detection for older, missing, or malformed versions. pnpm and Vite+ retain their legacy commands at every version because upstream native detection currently classifies their JS wrappers as npm-managed.
• Store the resolved maintenance capability with each provider snapshot so versionAdvisory.updateCommand, canUpdate, and runner execution stay aligned.
• Preserve package-manager lock grouping for native updates and reserve the Codex-native lock for standalone or otherwise unclassified installations.
• Preserve the configured provider-instance environment and effective home for native updates. Standalone executables override auth-overlay shadow homes with the shared installation home derived from the already-resolved path.
• Add strict semver validation and focused coverage for the stable boundary, prereleases, legacy managers, manual-only paths, configured executables, install context, and update concurrency.

Why

Codex added its native codex update command in openai/codex@b985768. It first appeared in 0.126.0-alpha.9, but 0.128.0 was the first stable npm release containing it, so this uses 0.128.0 as the conservative capability boundary.

Supported modern Codex installations can therefore perform their own installation-method detection instead of relying on T3 Code to invoke a package manager. Older or indeterminate installations, plus pnpm and Vite+ installations not currently supported by the native detector, continue using the existing behavior. Other provider drivers are unchanged.

Fixes#4066.

Related: #2765 covers Windows-specific child-process/PATH failures when spawning package-manager update commands. This PR may avoid that path for supported modern Codex installations, but it does not replace the Windows-specific fix.

Testing

• Focused provider-maintenance suite — 98 passed
• Provider-instance, adapter-registry, and Codex-home integration suite — 11 passed
• vp check — passed with 9 existing unrelated web lint warnings
• vp run typecheck — passed

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (no animation or interaction changes)

Note

Use native codex update command for Codex versions >= 0.128.0

• Introduces version-gated maintenance capability selection in codexMaintenance.ts: versions >= 0.128.0 use the native codex update command; older versions retain legacy package-manager (pnpm/vp) updates.
• Adds makeCodexMaintenanceEnvironment to set CODEX_HOME based on whether the executable is from a shared standalone install or an instance-specific path.
• Changes ServerProviderShape.maintenanceCapabilities from a synchronous property to getMaintenanceCapabilities, an Effect, allowing capabilities to update when the probed version changes.
• Extends ProviderMaintenanceCommandAction with an optional env field; ProviderMaintenanceRunner now passes this env (e.g. CODEX_HOME) to spawned update processes.
• Fixes parseSemver in both shared/src/semver.ts and providerMaintenance.ts to strip build metadata before parsing numeric segments.
• Behavioral Change: consumers of ServerProviderShape must now call getMaintenanceCapabilities as an Effect instead of reading a direct property.

^{Macroscope summarized 90b261b.}

---

Note

Medium Risk
Changes provider self-update execution (spawn env, version-gated commands) and makes maintenance capabilities async per snapshot; mistakes could run wrong update commands or misreport update availability for Codex.

Overview
Codex provider updates now prefer the probed executable’s native codex update flow when the installed version is valid semver and ≥ 0.128.0; older, missing, or malformed versions keep the existing package-manager path detection (with pnpm and vp always on legacy commands).

Maintenance capabilities are tied to the live snapshot:ServerProviderShape exposes getMaintenanceCapabilities as an Effect instead of a fixed field, and makeManagedServerProvider can resolveMaintenanceCapabilities after each probe so version advisories, canUpdate, and the update runner use the same command. Codex wires this through new codexMaintenance helpers (version gate, optional update env including CODEX_HOME for standalone installs) and resolveProviderMaintenanceCapabilitiesWithPathsEffect for resolved binary paths.

The maintenance runner forwards optional env into child-process spawn; shared semver gains isValidSemverVersion and build-metadata stripping in parseSemver.

^{Reviewed by Cursor Bugbot for commit e0ae1d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces version-gated maintenance capabilities that change how Codex updates are executed based on installed version. It adds new selection logic, interface changes (sync to Effect-based), and environment handling - significant runtime behavior changes that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 262ea88d-b6e4-40de-bf67-2246c27dca6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NicL9923]

Three install-context and update-coordination issues below. The capability/snapshot state plumbing and validation otherwise look solid.

[Dropje97]

Just added a second, independent reproduction of the underlying bug in #5629 — same standalone-installer layout, but with npm's global prefix set to ~/.local, the npm install -g fallback collides with the installer's own symlink and exits 1 (EEXIST) instead of silently installing a shadow copy. So on that configuration the in-app update isn't just cosmetically stuck, it fails outright with no path forward from the UI.

Mentioning it here mostly as a data point that the nativeUpdate path this PR adds fixes more than the "still needs an update" loop.

@Destreyf — this is currently conflicting against main and has been idle since late July. Any appetite to rebase it? Happy to test a rebased branch against a standalone install on Linux if that helps.

[Destreyf]

@Dropje97 should be rebased appropriately now.

[Dropje97]

Tested e0ae1d7 on Linux against a standalone install.

~/.local/bin/codex -> ~/.codex/packages/standalone/releases/0.151.0-x86_64-unknown-linux-musl/bin/codex
codex-cli 0.151.0, binaryPath left at the default "codex", CODEX_HOME unset

Before this PR the advisory resolves to the npm command, which exits 1 on this machine — my npm global prefix is ~/.local, the same bin dir the standalone installer owns, so npm's bin-link step hits EEXIST (this is #5629). Straight out of the provider cache on my running instance:

"status": "behind_latest", "currentVersion": "0.151.0", "latestVersion": "0.152.0",
"updateCommand": "npm install -g --allow-scripts=@openai/codex @openai/codex@latest"

With this PR, driving the real resolution code against my actual filesystem and the running server's PATH:

resolvedCommandPath = ~/.local/bin/codex
realCommandPath = ~/.codex/packages/standalone/releases/0.151.0-.../bin/codex
legacy = npm install -g --allow-scripts=@openai/codex @openai/codex@latest
selected = codex ["update"], lockKey "npm-global", CODEX_HOME=~/.codex
advisory = updateCommand "codex update", canUpdate true

The version gate lets 0.151.0 through, the standalone CODEX_HOME override fires, and the UI would show the native command instead of the broken npm one.

Test runs on the rebased branch: apps/server/src/provider 740 passed / 8 skipped / 0 failed, packages/shared/src/semver.test.ts 12 passed. Rebase looks clean from here — merge-base is exactly current main, no drift.

Two minor observations, neither a blocker:

1. This standalone install inherits lockKey: "npm-global" rather than codex-native, because the legacy layer classifies a bare binaryPath as npm. It over-serializes, so it is safe, and it looks deliberate and test-covered — just noting it reads differently from the literal wording of the earlier review point about lock grouping.
2. A standalone install located outside the configured home would not get the CODEX_HOME override, and would presumably be classified as "Other" by upstream's own detection. Not a regression, but uncovered. I am less confident about this one — I could not exercise that layout here.

Update — the native command was run end to end, and it works.

I ran it exactly as the runner would spawn it:

$ CODEX_HOME=~/.codex codex update
Updating Codex via `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh'`...
==> Updating Codex CLI from 0.151.0 to 0.152.0
==> Detected platform: Linux (x64)
==> Installing standalone package to ~/.codex/packages/standalone/releases/0.152.0-x86_64-unknown-linux-musl
==> ~/.local/bin is already on PATH
Codex CLI 0.152.0 installed successfully.
exit 0

Post-conditions checked:

• codex --version → codex-cli 0.152.0 (was 0.151.0)
• ~/.codex/packages/standalone/current correctly repointed to releases/0.152.0-..., symlink chain via ~/.local/bin/codex intact
• no npm copy created — ~/.local/lib/node_modules/ still contains no @openai/codex

That last point is the whole difference. Upstream's own install-context detection correctly identified the standalone layout and updated in place, where the legacy npm path either aborts with EEXIST (my prefix) or silently creates a second, unused install (the #5629 reporter's prefix).

So on this configuration the PR takes the provider from "update is impossible from the UI" to "update succeeds", verified end to end.

[Destreyf]

What Changed

• Use the configured Codex executable with structured ["update"] arguments when the installed version is valid semver and >= 0.128.0 and the installation is npm-, Bun-, Homebrew-, or standalone-managed. Default installations continue to execute codex update, while custom names and absolute paths update the same executable that was probed.
• Retain the existing npm, pnpm, Bun, Vite+, and Homebrew path detection for older, missing, or malformed versions. pnpm and Vite+ retain their legacy commands at every version because upstream native detection currently classifies their JS wrappers as npm-managed.
• Store the resolved maintenance capability with each provider snapshot so versionAdvisory.updateCommand, canUpdate, and runner execution stay aligned.
• Preserve package-manager lock grouping for native updates and reserve the Codex-native lock for standalone or otherwise unclassified installations.
• Preserve the configured provider-instance environment and effective home for native updates. Standalone executables override auth-overlay shadow homes with the shared installation home derived from the already-resolved path.
• Add strict semver validation and focused coverage for the stable boundary, prereleases, legacy managers, manual-only paths, configured executables, install context, and update concurrency.

Why

Codex added its native codex update command in openai/codex@b985768. It first appeared in 0.126.0-alpha.9, but 0.128.0 was the first stable npm release containing it, so this uses 0.128.0 as the conservative capability boundary.

Supported modern Codex installations can therefore perform their own installation-method detection instead of relying on T3 Code to invoke a package manager. Older or indeterminate installations, plus pnpm and Vite+ installations not currently supported by the native detector, continue using the existing behavior. Other provider drivers are unchanged.

Fixes#4066.

Related: #2765 covers Windows-specific child-process/PATH failures when spawning package-manager update commands. This PR may avoid that path for supported modern Codex installations, but it does not replace the Windows-specific fix.

Testing

• Focused provider-maintenance suite — 98 passed
• Provider-instance, adapter-registry, and Codex-home integration suite — 11 passed
• vp check — passed with 9 existing unrelated web lint warnings
• vp run typecheck — passed

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (no animation or interaction changes)

Note

Use native codex update command for Codex versions >= 0.128.0

• Introduces version-gated maintenance capability selection in codexMaintenance.ts: versions >= 0.128.0 use the native codex update command; older versions retain legacy package-manager (pnpm/vp) updates.
• Adds makeCodexMaintenanceEnvironment to set CODEX_HOME based on whether the executable is from a shared standalone install or an instance-specific path.
• Changes ServerProviderShape.maintenanceCapabilities from a synchronous property to getMaintenanceCapabilities, an Effect, allowing capabilities to update when the probed version changes.
• Extends ProviderMaintenanceCommandAction with an optional env field; ProviderMaintenanceRunner now passes this env (e.g. CODEX_HOME) to spawned update processes.
• Fixes parseSemver in both shared/src/semver.ts and providerMaintenance.ts to strip build metadata before parsing numeric segments.
• Behavioral Change: consumers of ServerProviderShape must now call getMaintenanceCapabilities as an Effect instead of reading a direct property.

^{Macroscope summarized 90b261b.}

---

Note

Medium Risk
Changes provider self-update execution (spawn env, version-gated commands) and makes maintenance capabilities async per snapshot; mistakes could run wrong update commands or misreport update availability for Codex.

Overview
Codex provider updates now prefer the probed executable’s native codex update flow when the installed version is valid semver and ≥ 0.128.0; older, missing, or malformed versions keep the existing package-manager path detection (with pnpm and vp always on legacy commands).

Maintenance capabilities are tied to the live snapshot:ServerProviderShape exposes getMaintenanceCapabilities as an Effect instead of a fixed field, and makeManagedServerProvider can resolveMaintenanceCapabilities after each probe so version advisories, canUpdate, and the update runner use the same command. Codex wires this through new codexMaintenance helpers (version gate, optional update env including CODEX_HOME for standalone installs) and resolveProviderMaintenanceCapabilitiesWithPathsEffect for resolved binary paths.

The maintenance runner forwards optional env into child-process spawn; shared semver gains isValidSemverVersion and build-metadata stripping in parseSemver.

^{Reviewed by Cursor Bugbot for commit e0ae1d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces version-gated maintenance capabilities that change how Codex updates are executed based on installed version. It adds new selection logic, interface changes (sync to Effect-based), and environment handling - significant runtime behavior changes that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 262ea88d-b6e4-40de-bf67-2246c27dca6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NicL9923]

Three install-context and update-coordination issues below. The capability/snapshot state plumbing and validation otherwise look solid.

[Dropje97]

Just added a second, independent reproduction of the underlying bug in #5629 — same standalone-installer layout, but with npm's global prefix set to ~/.local, the npm install -g fallback collides with the installer's own symlink and exits 1 (EEXIST) instead of silently installing a shadow copy. So on that configuration the in-app update isn't just cosmetically stuck, it fails outright with no path forward from the UI.

Mentioning it here mostly as a data point that the nativeUpdate path this PR adds fixes more than the "still needs an update" loop.

@Destreyf — this is currently conflicting against main and has been idle since late July. Any appetite to rebase it? Happy to test a rebased branch against a standalone install on Linux if that helps.

[Destreyf]

@Dropje97 should be rebased appropriately now.

[Dropje97]

Tested e0ae1d7 on Linux against a standalone install.

~/.local/bin/codex -> ~/.codex/packages/standalone/releases/0.151.0-x86_64-unknown-linux-musl/bin/codex
codex-cli 0.151.0, binaryPath left at the default "codex", CODEX_HOME unset

Before this PR the advisory resolves to the npm command, which exits 1 on this machine — my npm global prefix is ~/.local, the same bin dir the standalone installer owns, so npm's bin-link step hits EEXIST (this is #5629). Straight out of the provider cache on my running instance:

"status": "behind_latest", "currentVersion": "0.151.0", "latestVersion": "0.152.0",
"updateCommand": "npm install -g --allow-scripts=@openai/codex @openai/codex@latest"

With this PR, driving the real resolution code against my actual filesystem and the running server's PATH:

resolvedCommandPath = ~/.local/bin/codex
realCommandPath = ~/.codex/packages/standalone/releases/0.151.0-.../bin/codex
legacy = npm install -g --allow-scripts=@openai/codex @openai/codex@latest
selected = codex ["update"], lockKey "npm-global", CODEX_HOME=~/.codex
advisory = updateCommand "codex update", canUpdate true

The version gate lets 0.151.0 through, the standalone CODEX_HOME override fires, and the UI would show the native command instead of the broken npm one.

Test runs on the rebased branch: apps/server/src/provider 740 passed / 8 skipped / 0 failed, packages/shared/src/semver.test.ts 12 passed. Rebase looks clean from here — merge-base is exactly current main, no drift.

Two minor observations, neither a blocker:

1. This standalone install inherits lockKey: "npm-global" rather than codex-native, because the legacy layer classifies a bare binaryPath as npm. It over-serializes, so it is safe, and it looks deliberate and test-covered — just noting it reads differently from the literal wording of the earlier review point about lock grouping.
2. A standalone install located outside the configured home would not get the CODEX_HOME override, and would presumably be classified as "Other" by upstream's own detection. Not a regression, but uncovered. I am less confident about this one — I could not exercise that layout here.

Update — the native command was run end to end, and it works.

I ran it exactly as the runner would spawn it:

$ CODEX_HOME=~/.codex codex update
Updating Codex via `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh'`...
==> Updating Codex CLI from 0.151.0 to 0.152.0
==> Detected platform: Linux (x64)
==> Installing standalone package to ~/.codex/packages/standalone/releases/0.152.0-x86_64-unknown-linux-musl
==> ~/.local/bin is already on PATH
Codex CLI 0.152.0 installed successfully.
exit 0

Post-conditions checked:

• codex --version → codex-cli 0.152.0 (was 0.151.0)
• ~/.codex/packages/standalone/current correctly repointed to releases/0.152.0-..., symlink chain via ~/.local/bin/codex intact
• no npm copy created — ~/.local/lib/node_modules/ still contains no @openai/codex

That last point is the whole difference. Upstream's own install-context detection correctly identified the standalone layout and updated in place, where the legacy npm path either aborts with EEXIST (my prefix) or silently creates a second, unused install (the #5629 reporter's prefix).

So on this configuration the PR takes the provider from "update is impossible from the UI" to "update succeeds", verified end to end.

[Destreyf]

What Changed

• Use the configured Codex executable with structured ["update"] arguments when the installed version is valid semver and >= 0.128.0 and the installation is npm-, Bun-, Homebrew-, or standalone-managed. Default installations continue to execute codex update, while custom names and absolute paths update the same executable that was probed.
• Retain the existing npm, pnpm, Bun, Vite+, and Homebrew path detection for older, missing, or malformed versions. pnpm and Vite+ retain their legacy commands at every version because upstream native detection currently classifies their JS wrappers as npm-managed.
• Store the resolved maintenance capability with each provider snapshot so versionAdvisory.updateCommand, canUpdate, and runner execution stay aligned.
• Preserve package-manager lock grouping for native updates and reserve the Codex-native lock for standalone or otherwise unclassified installations.
• Preserve the configured provider-instance environment and effective home for native updates. Standalone executables override auth-overlay shadow homes with the shared installation home derived from the already-resolved path.
• Add strict semver validation and focused coverage for the stable boundary, prereleases, legacy managers, manual-only paths, configured executables, install context, and update concurrency.

Why

Codex added its native codex update command in openai/codex@b985768. It first appeared in 0.126.0-alpha.9, but 0.128.0 was the first stable npm release containing it, so this uses 0.128.0 as the conservative capability boundary.

Supported modern Codex installations can therefore perform their own installation-method detection instead of relying on T3 Code to invoke a package manager. Older or indeterminate installations, plus pnpm and Vite+ installations not currently supported by the native detector, continue using the existing behavior. Other provider drivers are unchanged.

Fixes#4066.

Related: #2765 covers Windows-specific child-process/PATH failures when spawning package-manager update commands. This PR may avoid that path for supported modern Codex installations, but it does not replace the Windows-specific fix.

Testing

• Focused provider-maintenance suite — 98 passed
• Provider-instance, adapter-registry, and Codex-home integration suite — 11 passed
• vp check — passed with 9 existing unrelated web lint warnings
• vp run typecheck — passed

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (no animation or interaction changes)

Note

Use native codex update command for Codex versions >= 0.128.0

• Introduces version-gated maintenance capability selection in codexMaintenance.ts: versions >= 0.128.0 use the native codex update command; older versions retain legacy package-manager (pnpm/vp) updates.
• Adds makeCodexMaintenanceEnvironment to set CODEX_HOME based on whether the executable is from a shared standalone install or an instance-specific path.
• Changes ServerProviderShape.maintenanceCapabilities from a synchronous property to getMaintenanceCapabilities, an Effect, allowing capabilities to update when the probed version changes.
• Extends ProviderMaintenanceCommandAction with an optional env field; ProviderMaintenanceRunner now passes this env (e.g. CODEX_HOME) to spawned update processes.
• Fixes parseSemver in both shared/src/semver.ts and providerMaintenance.ts to strip build metadata before parsing numeric segments.
• Behavioral Change: consumers of ServerProviderShape must now call getMaintenanceCapabilities as an Effect instead of reading a direct property.

^{Macroscope summarized 90b261b.}

---

Note

Medium Risk
Changes provider self-update execution (spawn env, version-gated commands) and makes maintenance capabilities async per snapshot; mistakes could run wrong update commands or misreport update availability for Codex.

Overview
Codex provider updates now prefer the probed executable’s native codex update flow when the installed version is valid semver and ≥ 0.128.0; older, missing, or malformed versions keep the existing package-manager path detection (with pnpm and vp always on legacy commands).

Maintenance capabilities are tied to the live snapshot:ServerProviderShape exposes getMaintenanceCapabilities as an Effect instead of a fixed field, and makeManagedServerProvider can resolveMaintenanceCapabilities after each probe so version advisories, canUpdate, and the update runner use the same command. Codex wires this through new codexMaintenance helpers (version gate, optional update env including CODEX_HOME for standalone installs) and resolveProviderMaintenanceCapabilitiesWithPathsEffect for resolved binary paths.

The maintenance runner forwards optional env into child-process spawn; shared semver gains isValidSemverVersion and build-metadata stripping in parseSemver.

^{Reviewed by Cursor Bugbot for commit e0ae1d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces version-gated maintenance capabilities that change how Codex updates are executed based on installed version. It adds new selection logic, interface changes (sync to Effect-based), and environment handling - significant runtime behavior changes that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 262ea88d-b6e4-40de-bf67-2246c27dca6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NicL9923]

Three install-context and update-coordination issues below. The capability/snapshot state plumbing and validation otherwise look solid.

[Dropje97]

Just added a second, independent reproduction of the underlying bug in #5629 — same standalone-installer layout, but with npm's global prefix set to ~/.local, the npm install -g fallback collides with the installer's own symlink and exits 1 (EEXIST) instead of silently installing a shadow copy. So on that configuration the in-app update isn't just cosmetically stuck, it fails outright with no path forward from the UI.

Mentioning it here mostly as a data point that the nativeUpdate path this PR adds fixes more than the "still needs an update" loop.

@Destreyf — this is currently conflicting against main and has been idle since late July. Any appetite to rebase it? Happy to test a rebased branch against a standalone install on Linux if that helps.

[Destreyf]

@Dropje97 should be rebased appropriately now.

[Dropje97]

Tested e0ae1d7 on Linux against a standalone install.

~/.local/bin/codex -> ~/.codex/packages/standalone/releases/0.151.0-x86_64-unknown-linux-musl/bin/codex
codex-cli 0.151.0, binaryPath left at the default "codex", CODEX_HOME unset

Before this PR the advisory resolves to the npm command, which exits 1 on this machine — my npm global prefix is ~/.local, the same bin dir the standalone installer owns, so npm's bin-link step hits EEXIST (this is #5629). Straight out of the provider cache on my running instance:

"status": "behind_latest", "currentVersion": "0.151.0", "latestVersion": "0.152.0",
"updateCommand": "npm install -g --allow-scripts=@openai/codex @openai/codex@latest"

With this PR, driving the real resolution code against my actual filesystem and the running server's PATH:

resolvedCommandPath = ~/.local/bin/codex
realCommandPath = ~/.codex/packages/standalone/releases/0.151.0-.../bin/codex
legacy = npm install -g --allow-scripts=@openai/codex @openai/codex@latest
selected = codex ["update"], lockKey "npm-global", CODEX_HOME=~/.codex
advisory = updateCommand "codex update", canUpdate true

The version gate lets 0.151.0 through, the standalone CODEX_HOME override fires, and the UI would show the native command instead of the broken npm one.

Test runs on the rebased branch: apps/server/src/provider 740 passed / 8 skipped / 0 failed, packages/shared/src/semver.test.ts 12 passed. Rebase looks clean from here — merge-base is exactly current main, no drift.

Two minor observations, neither a blocker:

1. This standalone install inherits lockKey: "npm-global" rather than codex-native, because the legacy layer classifies a bare binaryPath as npm. It over-serializes, so it is safe, and it looks deliberate and test-covered — just noting it reads differently from the literal wording of the earlier review point about lock grouping.
2. A standalone install located outside the configured home would not get the CODEX_HOME override, and would presumably be classified as "Other" by upstream's own detection. Not a regression, but uncovered. I am less confident about this one — I could not exercise that layout here.

Update — the native command was run end to end, and it works.

I ran it exactly as the runner would spawn it:

$ CODEX_HOME=~/.codex codex update
Updating Codex via `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh'`...
==> Updating Codex CLI from 0.151.0 to 0.152.0
==> Detected platform: Linux (x64)
==> Installing standalone package to ~/.codex/packages/standalone/releases/0.152.0-x86_64-unknown-linux-musl
==> ~/.local/bin is already on PATH
Codex CLI 0.152.0 installed successfully.
exit 0

Post-conditions checked:

• codex --version → codex-cli 0.152.0 (was 0.151.0)
• ~/.codex/packages/standalone/current correctly repointed to releases/0.152.0-..., symlink chain via ~/.local/bin/codex intact
• no npm copy created — ~/.local/lib/node_modules/ still contains no @openai/codex

That last point is the whole difference. Upstream's own install-context detection correctly identified the standalone layout and updated in place, where the legacy npm path either aborts with EEXIST (my prefix) or silently creates a second, unused install (the #5629 reporter's prefix).

So on this configuration the PR takes the provider from "update is impossible from the UI" to "update succeeds", verified end to end.

[Destreyf]

What Changed

• Use the configured Codex executable with structured ["update"] arguments when the installed version is valid semver and >= 0.128.0 and the installation is npm-, Bun-, Homebrew-, or standalone-managed. Default installations continue to execute codex update, while custom names and absolute paths update the same executable that was probed.
• Retain the existing npm, pnpm, Bun, Vite+, and Homebrew path detection for older, missing, or malformed versions. pnpm and Vite+ retain their legacy commands at every version because upstream native detection currently classifies their JS wrappers as npm-managed.
• Store the resolved maintenance capability with each provider snapshot so versionAdvisory.updateCommand, canUpdate, and runner execution stay aligned.
• Preserve package-manager lock grouping for native updates and reserve the Codex-native lock for standalone or otherwise unclassified installations.
• Preserve the configured provider-instance environment and effective home for native updates. Standalone executables override auth-overlay shadow homes with the shared installation home derived from the already-resolved path.
• Add strict semver validation and focused coverage for the stable boundary, prereleases, legacy managers, manual-only paths, configured executables, install context, and update concurrency.

Why

Codex added its native codex update command in openai/codex@b985768. It first appeared in 0.126.0-alpha.9, but 0.128.0 was the first stable npm release containing it, so this uses 0.128.0 as the conservative capability boundary.

Supported modern Codex installations can therefore perform their own installation-method detection instead of relying on T3 Code to invoke a package manager. Older or indeterminate installations, plus pnpm and Vite+ installations not currently supported by the native detector, continue using the existing behavior. Other provider drivers are unchanged.

Fixes#4066.

Related: #2765 covers Windows-specific child-process/PATH failures when spawning package-manager update commands. This PR may avoid that path for supported modern Codex installations, but it does not replace the Windows-specific fix.

Testing

• Focused provider-maintenance suite — 98 passed
• Provider-instance, adapter-registry, and Codex-home integration suite — 11 passed
• vp check — passed with 9 existing unrelated web lint warnings
• vp run typecheck — passed

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (no UI changes)
• I included a video for animation/interaction changes (no animation or interaction changes)

Note

Use native codex update command for Codex versions >= 0.128.0

• Introduces version-gated maintenance capability selection in codexMaintenance.ts: versions >= 0.128.0 use the native codex update command; older versions retain legacy package-manager (pnpm/vp) updates.
• Adds makeCodexMaintenanceEnvironment to set CODEX_HOME based on whether the executable is from a shared standalone install or an instance-specific path.
• Changes ServerProviderShape.maintenanceCapabilities from a synchronous property to getMaintenanceCapabilities, an Effect, allowing capabilities to update when the probed version changes.
• Extends ProviderMaintenanceCommandAction with an optional env field; ProviderMaintenanceRunner now passes this env (e.g. CODEX_HOME) to spawned update processes.
• Fixes parseSemver in both shared/src/semver.ts and providerMaintenance.ts to strip build metadata before parsing numeric segments.
• Behavioral Change: consumers of ServerProviderShape must now call getMaintenanceCapabilities as an Effect instead of reading a direct property.

^{Macroscope summarized 90b261b.}

---

Note

Medium Risk
Changes provider self-update execution (spawn env, version-gated commands) and makes maintenance capabilities async per snapshot; mistakes could run wrong update commands or misreport update availability for Codex.

Overview
Codex provider updates now prefer the probed executable’s native codex update flow when the installed version is valid semver and ≥ 0.128.0; older, missing, or malformed versions keep the existing package-manager path detection (with pnpm and vp always on legacy commands).

Maintenance capabilities are tied to the live snapshot:ServerProviderShape exposes getMaintenanceCapabilities as an Effect instead of a fixed field, and makeManagedServerProvider can resolveMaintenanceCapabilities after each probe so version advisories, canUpdate, and the update runner use the same command. Codex wires this through new codexMaintenance helpers (version gate, optional update env including CODEX_HOME for standalone installs) and resolveProviderMaintenanceCapabilitiesWithPathsEffect for resolved binary paths.

The maintenance runner forwards optional env into child-process spawn; shared semver gains isValidSemverVersion and build-metadata stripping in parseSemver.

^{Reviewed by Cursor Bugbot for commit e0ae1d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces version-gated maintenance capabilities that change how Codex updates are executed based on installed version. It adds new selection logic, interface changes (sync to Effect-based), and environment handling - significant runtime behavior changes that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 262ea88d-b6e4-40de-bf67-2246c27dca6a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[NicL9923]

Three install-context and update-coordination issues below. The capability/snapshot state plumbing and validation otherwise look solid.

[Dropje97]

Just added a second, independent reproduction of the underlying bug in #5629 — same standalone-installer layout, but with npm's global prefix set to ~/.local, the npm install -g fallback collides with the installer's own symlink and exits 1 (EEXIST) instead of silently installing a shadow copy. So on that configuration the in-app update isn't just cosmetically stuck, it fails outright with no path forward from the UI.

Mentioning it here mostly as a data point that the nativeUpdate path this PR adds fixes more than the "still needs an update" loop.

@Destreyf — this is currently conflicting against main and has been idle since late July. Any appetite to rebase it? Happy to test a rebased branch against a standalone install on Linux if that helps.

[Destreyf]

@Dropje97 should be rebased appropriately now.

[Dropje97]

Tested e0ae1d7 on Linux against a standalone install.

~/.local/bin/codex -> ~/.codex/packages/standalone/releases/0.151.0-x86_64-unknown-linux-musl/bin/codex
codex-cli 0.151.0, binaryPath left at the default "codex", CODEX_HOME unset

Before this PR the advisory resolves to the npm command, which exits 1 on this machine — my npm global prefix is ~/.local, the same bin dir the standalone installer owns, so npm's bin-link step hits EEXIST (this is #5629). Straight out of the provider cache on my running instance:

"status": "behind_latest", "currentVersion": "0.151.0", "latestVersion": "0.152.0",
"updateCommand": "npm install -g --allow-scripts=@openai/codex @openai/codex@latest"

With this PR, driving the real resolution code against my actual filesystem and the running server's PATH:

resolvedCommandPath = ~/.local/bin/codex
realCommandPath = ~/.codex/packages/standalone/releases/0.151.0-.../bin/codex
legacy = npm install -g --allow-scripts=@openai/codex @openai/codex@latest
selected = codex ["update"], lockKey "npm-global", CODEX_HOME=~/.codex
advisory = updateCommand "codex update", canUpdate true

The version gate lets 0.151.0 through, the standalone CODEX_HOME override fires, and the UI would show the native command instead of the broken npm one.

Test runs on the rebased branch: apps/server/src/provider 740 passed / 8 skipped / 0 failed, packages/shared/src/semver.test.ts 12 passed. Rebase looks clean from here — merge-base is exactly current main, no drift.

Two minor observations, neither a blocker:

1. This standalone install inherits lockKey: "npm-global" rather than codex-native, because the legacy layer classifies a bare binaryPath as npm. It over-serializes, so it is safe, and it looks deliberate and test-covered — just noting it reads differently from the literal wording of the earlier review point about lock grouping.
2. A standalone install located outside the configured home would not get the CODEX_HOME override, and would presumably be classified as "Other" by upstream's own detection. Not a regression, but uncovered. I am less confident about this one — I could not exercise that layout here.

Update — the native command was run end to end, and it works.

I ran it exactly as the runner would spawn it:

$ CODEX_HOME=~/.codex codex update
Updating Codex via `sh -c 'curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh'`...
==> Updating Codex CLI from 0.151.0 to 0.152.0
==> Detected platform: Linux (x64)
==> Installing standalone package to ~/.codex/packages/standalone/releases/0.152.0-x86_64-unknown-linux-musl
==> ~/.local/bin is already on PATH
Codex CLI 0.152.0 installed successfully.
exit 0

Post-conditions checked:

• codex --version → codex-cli 0.152.0 (was 0.151.0)
• ~/.codex/packages/standalone/current correctly repointed to releases/0.152.0-..., symlink chain via ~/.local/bin/codex intact
• no npm copy created — ~/.local/lib/node_modules/ still contains no @openai/codex

That last point is the whole difference. Upstream's own install-context detection correctly identified the standalone layout and updated in place, where the legacy npm path either aborts with EEXIST (my prefix) or silently creates a second, unused install (the #5629 reporter's prefix).

So on this configuration the PR takes the provider from "update is impossible from the UI" to "update succeeds", verified end to end.