Pin Your Coding Agent Tools to a Version That Works
You will check which tool versions you run, record a known-good one, and pin it so a bad nightly or a breaking server change does not stop your work. This reduces risk from unreviewed updates to agent tooling.
- Record versionsNote the exact version and date you confirmed it works
- Pin the releaseUse a stable build, not a nightly, in your lockfile
- Test on a throwaway projectRun a prompt, an edit, and one tool call
- Upgrade deliberatelyMove the pin forward only after the test passes
Why it matters
Agent tooling changes fast, and recent builds have broken working setups. Gemini CLI users reported tasks stopping with "[API Error: Model stream ended with empty response text.]" on a 0.9.0 nightly (source (opens external site)), and a later release froze mid-session with no confirmed fix (source (opens external site)). On the MCP side, the official Brave Search server hit "Rate limit exceeded" from its own parallel requests, and the project was archived without a fix (source (opens external site)). When an update breaks something you depend on, you want to be able to go back to a version you know works.
Steps
-
Record the exact version of every agent CLI and MCP server you use, along with the date you confirmed it works. Do this for both your main machine and any CI or shared environment.
-
Install the stable release you verified, not the latest nightly. Pin the version in your package manager or lockfile so a reinstall does not pull something newer. Avoid nightly builds for anything you rely on daily.
-
Before upgrading, run a short test task on a throwaway project: a simple prompt, a code edit, and one MCP tool call. Only move your working setup forward after that passes.
-
If a version starts misbehaving, save the session first. In Gemini CLI, the workaround that worked for one user was running
/chat save errors, exiting, restarting, running/chat resume errors, and asking it to continue. This did not help everyone, so treat it as a stopgap, not a fix. -
If the problem persists, clear local CLI state and retest. One user uninstalled the CLI, ran
cd $HOME, removed the.geminidirectory, reinstalled, and tested with a simple "hi" before returning to the project. Back up anything you care about first. -
For freezes, test outside
tmuxif you normally use it. One user only saw the freeze undertmuxon the same machine (source (opens external site)). -
For MCP servers that call rate-limited APIs, reduce concurrency. The Brave server fires two requests at once through
Promise.all, which exceeds the free-tier limit of 1 query per second (source (opens external site)). Use the web search tool if you do not need the extra data, and keep API keys in environment variables rather than config files that could be committed.
Common mistakes
- Upgrading everything at once, so you cannot tell which change broke your setup.
- Treating a closed issue as a fix. Several of these threads were closed with no patch in them.
- Pinning the version but not the config, so a changed default or a leftover state directory causes the new breakage.
- Assuming an archived server will get fixes. Once a project moves to an archive, plan a replacement.
Checklist
0 of 7 done