Before submitting
Area
apps/server
Problem or use case
T3 Code currently chooses the Codex update command by inspecting the resolved installation path and then invoking npm, pnpm, Bun, Vite+, or Homebrew. Modern Codex releases can perform this installation-method detection themselves through the native codex update command.
This is distinct from #2765, which reports Windows-specific child-process/PATH failures when spawning the existing package-manager command. The capability-selection change here is cross-platform and version-dependent.
Proposed solution
When the installed Codex version is valid semver and >= 0.128.0, use structured executable/argument fields for codex with ["update"].
For older versions, or when the installed version is missing or malformed, retain the existing installation-path-based package-manager selection. Keep the resolved capability shared between the displayed version advisory and the maintenance runner, and preserve the configured provider-instance environment.
Why this matters
This delegates installation detection to Codex on versions that support it, reducing duplicated package-manager assumptions in T3 Code while preserving compatibility for older installations. It also makes update behavior more consistent across installation methods and platforms.
Smallest useful scope
Apply the native update path only to the built-in Codex driver at the conservative stable boundary of 0.128.0. Do not change Claude, OpenCode, Cursor, Grok, or custom provider drivers.
Alternatives considered
- Continue extending T3 Code installation-path heuristics for every package manager.
- Use the first prerelease containing the command, 0.126.0-alpha.9.
The stable 0.128.0 boundary is more conservative, and retaining the existing path below it avoids optimistic native command execution.
Risks or tradeoffs
- Prereleases below 0.128.0 that technically support
codex update continue using the legacy path.
- Missing or non-semver versions cannot opt into the native command.
- Capability selection must occur after the provider status probe without creating a second independent command-selection path.
Examples or references
Contribution
Before submitting
Area
apps/server
Problem or use case
T3 Code currently chooses the Codex update command by inspecting the resolved installation path and then invoking npm, pnpm, Bun, Vite+, or Homebrew. Modern Codex releases can perform this installation-method detection themselves through the native
codex updatecommand.This is distinct from #2765, which reports Windows-specific child-process/PATH failures when spawning the existing package-manager command. The capability-selection change here is cross-platform and version-dependent.
Proposed solution
When the installed Codex version is valid semver and >= 0.128.0, use structured executable/argument fields for
codexwith["update"].For older versions, or when the installed version is missing or malformed, retain the existing installation-path-based package-manager selection. Keep the resolved capability shared between the displayed version advisory and the maintenance runner, and preserve the configured provider-instance environment.
Why this matters
This delegates installation detection to Codex on versions that support it, reducing duplicated package-manager assumptions in T3 Code while preserving compatibility for older installations. It also makes update behavior more consistent across installation methods and platforms.
Smallest useful scope
Apply the native update path only to the built-in Codex driver at the conservative stable boundary of 0.128.0. Do not change Claude, OpenCode, Cursor, Grok, or custom provider drivers.
Alternatives considered
The stable 0.128.0 boundary is more conservative, and retaining the existing path below it avoids optimistic native command execution.
Risks or tradeoffs
codex updatecontinue using the legacy path.Examples or references
codex updatecommand openai/codex#19933Contribution