[Bug]: pnpm-global Codex update installs nothing because @latest resolves under pnpm's minimumReleaseAge #14249

Activity

1. Neonsy

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 29, 2026
2. Neonsy

   changed the title [-][Bug]: pnpm-global Codex update silently does nothing while the new release is inside pnpm's minimum release age[/-] [+][Bug]: pnpm-global Codex update installs nothing because `@latest` resolves under pnpm's minimumReleaseAge[/+] on Sep 29, 2026
3. juliusmarminge commented on Sep 29, 2026

   

   juliusmarminge

   on Sep 29, 2026

   Member

   More actions

   Triage

   Confirmed on current main. Not a duplicate.

   The pnpm-global update is pnpm add -g <package>@latest (resolvePackageManagedProviderMaintenance in apps/server/src/provider/providerMaintenance.ts). The advertised version is the npm latest dist-tag (fetchNpmLatestVersion requests registry.npmjs.org/<package>/latest) with no release-age check. That tag is 0.159.0 for @openai/codex right now.

   pnpm 11+ defaults minimumReleaseAge to 1440 minutes. With no override, that default is non-strict, so @latest resolves to the newest version old enough to pass and the command exits 0 without mentioning the skipped release. That matches this report: updateProvider and runCommand succeed because pnpm exited 0, Codex stays on 0.158.0, and the advisory stays behind_latest, so the prompt stays.

   The in-app result should not be a green "Provider updated". After a zero exit, ProviderMaintenanceRunner marks the update unchanged when the refreshed advisory is still behind_latest, and the toast is the warning "Provider still needs an update". pnpm is the part that prints no reason.

   The ordinary Update button does not pin a version. makeTargetedProviderUpdateAction can rewrite a pnpm-global @latest argument to an exact version, but that only runs when targetVersion is set (the compatibility "install recommended" action). The copyable command is the same @latest string, so running it by hand does the same thing.

   This is every provider installed as a pnpm global, not only Codex. npm and bun also update with @latest, but they do not have this default age gate. Homebrew already avoids the same mismatch by taking latestVersion from brew info instead of npm.

   Closed PR #8363 was about a different pnpm-global failure (install scripts skipped while the command still exits 0). It did not cover release age.

   Both fixes in the report fit the code that is already there:

   • Pin the pnpm command, including the copyable one, to the version on screen. The targeted-update helper already does that rewrite, and on pnpm 12.6.0 an exact spec installs and records minimumReleaseAgeExclude. That bypasses the default cooldown for that version. pnpm's older crash on immature exact global installs (pnpm add -g crashes with unhandled resolution-policy violations when minimumReleaseAge blocks an exact global install pnpm/pnpm#11748) was fixed.
   • Or keep @latest and only advertise the newest version pnpm would actually install, the same way Homebrew compares against what brew upgrade can deliver.

   No further info needed.
4. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 29, 2026
5. Neonsy commented on Oct 5, 2026

   

   Neonsy

   on Oct 5, 2026

   Author

   More actions

   Wanted to note that I just saw the manual suggestion command on the currently latest nightly to be:

   PATH-TO PNPM\bin\codex.CMD update

   but that causes the same skip
6. HerbCaudill commented on Oct 10, 2026

   

   HerbCaudill

   on Oct 10, 2026

   More actions

   Same issue here.

   A workaround is to exclude Codex from pnpm's release-age wait:

   pnpm config set --location=global --json minimumReleaseAgeExclude '["@openai/codex"]'

   This adds the following to your global pnpm config (~/Library/Preferences/pnpm/config.yaml on macOS):

   minimumReleaseAgeExclude:
     - '@openai/codex'

   After that, pnpm add -g @openai/codex@latest installs the newest release right away, and T3's update button works. The tradeoff is that you lose the one-day buffer for Codex. Every other package keeps it.

   If you already have entries in minimumReleaseAgeExclude, add @openai/codex to your existing list. The command above replaces the whole list.
7. beanow-at-crabnebula commented on Oct 16, 2026

   

   beanow-at-crabnebula

   on Oct 16, 2026

   Last edited by beanow-at-crabnebula

   More actions

   The workaround of minimumReleaseAgeExclude will of course work.

   However I think the preferred solution would be to respect the pnpm policy. There are far too many malware on NPM incidents to discard this very sensible measure that pnpm made the default.

   I would find it rather concerning if T3code was making automatic decisions to grant exceptions for a security-sensitive policy like this too. So I don't think it should add the exception just for the UX paper cut, undermining the security model.

   PNPM itself can confirm whether a provider "still needs updates".

   $ pnpm outdated -g --format json @openai/codex @anthropic-ai/claude-code [...]
   
   {
     "@anthropic-ai/claude-code": {
       "current": "2.1.299",
       "latest": "2.1.300",
       "wanted": "2.1.299",
       "isDeprecated": false,
       "dependencyType": "dependencies"
     }
   }
   

   At the time of writing, 2.1.301 is the actual latest Claude release, but 2.1.300 is the latest that is past for the minimum age threshold.

   This would avoid hard-coding / guessing what the configured age is for your machine. As well as being able to respect any exceptions to the policy, including when it's a particular version range or particular package.

   It looks like #19580 implements exactly that.
8. juliusmarminge commented on Oct 19, 2026

   

   juliusmarminge

   on Oct 19, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Fixed by #14295, which just merged: pnpm-global provider updates now install the exact version T3 Code advertises instead of @latest, in both the Update action and the copyable command. Whether updates should instead respect pnpm's release-age delay is being tracked separately in #15329. Closing as completed; it'll ship in the next nightly.
9. juliusmarminge

   closed this as completedon Oct 19, 2026