Warm the pinned CLI version, not @latest
A plugin that downloads its CLI on first use can miss a short hook timeout. Warm the version and runner the plugin will use.
You install a plugin for your coding agent, and the plugin needs a command line tool (CLI) that isn't on your machine yet. The first time one of its hooks runs, that CLI has to be downloaded before anything else can happen. A hook is a command the agent runs at fixed points, for example after each shell command. A hook can have a short time limit. Codex gives plugin hooks 10 seconds.
How a plugin gets its CLI
Some plugins don't bundle the CLI. They ask a package runner for it: bunx (Bun's) or npx (npm's). A package runner downloads a package into its cache and runs it without a global install. The plugin names an exact version, for example @1.2.3. That's the pinned version, and it changes when the plugin updates.
The download only happens once per version and runner. After that, the cache answers. So the question is whether the first, cold run fits inside the hook's time limit.
Your options
| Option | Good | Risk |
|---|---|---|
| Do nothing | No extra step | The first hook may run out of time while it downloads |
Warm @latest by hand | Easy to type | Fills the cache with the newest release, which may not be the pinned one |
| Install the CLI globally | Fast every time | If the plugin prefers an installed CLI, it runs whatever version you installed, not its pin |
| Run the plugin's own launcher once | Same runner and same version the hook will use | You have to find where the plugin is installed |
The hand-typed warm-up has a second problem. Bun and npm keep separate caches. If the plugin tries bunx first and Bun is on your machine, warming with npx does nothing for the hook.
Think of two pantries, one for Bun and one for npm. The hook cooks from the first pantry it finds and asks for one exact item. Stocking the other pantry, or the right pantry with a newer item, leaves the hook waiting. Where it stops fitting: you can see an empty shelf, but an empty cache only shows up as a slow first run.
Warm what the hook will use
The plugin's launcher (the small script its hooks call) already knows which runner and which version to use. Run it once with a harmless command, such as asking for the version. That fills the right cache with the right version.
The spatz plugins work this way. Their launcher tries an installed spatz first, then bunx, then npx, each with the plugin's exact version. The first download is about 60 MB, and the spatz docs warn that a cold download can take longer than Codex's 10 seconds. On my development VM, one run each on 2026-10-05:
| Runner | First run (cold cache) | Later run (warm cache) |
|---|---|---|
bunx | 1.9 s | about 0.06 s |
npx | 5.0 s | about 0.9 s |
That machine stayed under 10 seconds with both runners. The second run was about 30 times faster with bunx and about 5 times faster with npx.
Try it: find your plugin's launcher (for Codex, the plugin list shows where it is installed), run it twice in a row and compare the times.