You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
This discussion was converted from issue #4066 on August 15, 2026 09:44.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
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
All reactions