Your AI coding tool broke after an auto-update? On Windows, check the self-lock first

I've been collecting these reports for a while now, and there's a pattern. Your AI coding assistant says "Update complete!", you click it, and then... the tool won't start. Or it crashes. Or every launch says "the next launch will retry" forever.

It's not bad luck. It's Windows file locking meeting self-updaters that report success before anything actually finished.

The pattern

AI coding tools update themselves. On Windows that means replacing .exe files, renaming venv folders, rewriting npm shims. And Windows will not let you replace a file that's running, or rename a folder a process has open.

Look at what people actually hit:

• hermes update fails with [WinError 32] ...hermes.exe -> hermes.exe.deleteme. The updater IS hermes.exe, so it can't replace itself. Then it drops a .update-incomplete marker, and every launch retries the update and fails again. Permanent loop.
• The same updater can't "park" its own venv: WinError 5 Access denied renaming venv to venv.stale.runtime-*, because leftover gateway and desktop processes spawned from inside that venv still have python.exe open.
• Claude Code auto-updates 2.1.236 to 2.1.237 and leaves a 500-byte claude.exe stub that prints "Error: claude native binary not installed." The Windows platform package was never published to npm, and the updater logged success anyway.
• cline update half-writes the global npm install and the cline command just vanishes from PATH.

The common thread: the updater replaces files while old processes still hold them, and it reports success regardless.

Why "Update complete!" lies to you

Three things stack up:

1. Windows locks files that are in use. A running exe can't be swapped. A directory a process is sitting in can't be renamed. On Linux, unlinking an open file works fine; Windows says no.
2. Self-updaters skip themselves in their own "is anything running?" check. The process doing the updating excludes itself and its ancestors from the lock scan, so it never sees the conflict right under its nose.
3. Exit code 0 doesn't mean done. The updater prints "Update complete!" because the shell command returned 0, even when the file it needed to write never landed.

The fix recipe

When your agent CLI breaks after an auto-update on Windows, go through this in order:

1. Kill everything from the old install. Task Manager: the CLI, the desktop app, the gateway or background server, stray node.exe processes. Quit tray apps properly, then check again, because many of these keep a background daemon alive.
2. Clear stale markers and caches. Look for .update-incomplete, update-in-progress, venv.rollback-bak-*, generation-*, and __pycache__ folders under the install dir and delete them. If node_modules is half-installed, delete it too.
3. Update from a clean shell outside the app's own process tree. Don't run the updater from inside the tool's own terminal. For hermes specifically, python -m hermes_cli.main update runs the updater via python.exe instead of the launcher, so the file being replaced isn't the one running the update.
4. Verify, don't trust. After updating, run claude --version / hermes --version / cline --version. Check the binary is actually a binary, not a stub: dir the exe and look at the size. For npm-installed CLIs, npm view <pkg>@<version> confirms the package exists before you re-run the update.
5. Pin or downgrade as a stopgap. If the new version is broken, install the last known-good one explicitly: npm i -g cline@<oldver>, npm install -g @anthropic-ai/claude-code@2.1.236. A working older version beats a broken new one, and disable auto-update until the next release.

Already stuck in the loop?

If every launch says "the next launch will retry", kill the process, delete the marker file (.update-incomplete or whatever it's called), and run the update manually from a clean shell. The marker is just a file. Deleting it breaks the loop.

Why this keeps happening

It's not one bug. It's the combination of Windows' file-locking semantics, updaters that report success before verifying, and self-updaters that can't see their own conflict. Each vendor is patching their own instance (hermes merged a fix that re-runs the updater via python.exe when it detects a shim launch; the Claude Code one was a missing npm publish), but the class of problem will keep showing up as long as tools replace their own running files on Windows.

So before you reinstall from scratch, try the five steps. In my experience, most of the time it's a locked file and a lying success message, not a corrupt install.

Sources: hermes-agent #89599, hermes-agent #93032, claude-code #88105, cline #13115