[Feature]: Use native Codex updates for supported CLI versions #4066

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

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

• Native command implementation: openai/codex@b985768 / Add codex update command openai/codex#19933
• First stable npm release containing the command: 0.128.0
• Related but distinct Windows spawn issue: [Bug]: Codex Update Always Failing #2765

Contribution

• I would be open to helping implement this.