The fourth tool in the manifest
Bringing pnpm into the developer-tool update policy, replacing manual version chores while keeping CI reproducible.
The developer CLI update policy covered Claude Code, Codex, and Antigravity, but the devcontainer had a fourth fast-moving tool: pnpm. Its own update notice had produced a ticket whose entire requirement was moving from one known version to another. The better answer was not another version-only pull request, it was to bring the package manager under the same lifecycle policy.
Fresh locally, pinned in CI#
pnpm did not fit the existing updater quite as neatly as the three agent CLIs. They know how to update themselves, while pnpm is installed through npm. The shared manifest therefore gained enough information to check the registry, install a newer package-manager release, and verify the resulting binary. After an update, a small synchronization step records the installed pnpm version in package.json, which is the version CI reads on its next reviewed commit.
Startup still has to be resilient. A failed version lookup or installation reports a warning and leaves the existing package manager in place, and the synchronization step can be disabled locally. That keeps tool freshness from becoming a prerequisite for opening the repository, while still making the normal path automatic.
The practical expectation is that package-manager upgrades now arrive through ordinary development instead of dedicated reminder tickets. More importantly, the manifest is becoming a policy for the tools needed to operate the repository, not a special case for whichever binaries happen to call themselves agents.