How to Update and Completely Uninstall an AI Coding CLI Tool on Windows

Identify the installation form first

Most command-line AI coding tools on Windows ship as a single executable, commonly named mytool.exe. This article uses mytool as a stand-in for the actual tool. Next to the executable there may be a configuration directory, a cache directory, or supporting library files. The user’s home directory usually contains a hidden, dot-prefixed configuration folder, such as %USERPROFILE%\.mytool. Some tools also add their launch directory to the user’s PATH environment variable.

Updating and uninstalling therefore target different things. An update only needs to replace the executable and confirm that the configuration directory works with the new version. Uninstalling must remove the executable, configuration, cache, PATH entries, and any leftover registry keys. Back up before either operation. The backup is the only basis for rolling back.

Preparation: back up and check the environment

First, check in PowerShell whether the hidden configuration directory exists. Hidden items do not appear by default, so use the -Force parameter:

Get-ChildItem -Force $env:USERPROFILE | Where-Object Name -like ".mytool*"

Back up the current executable and the configuration directory. Store the backups outside the installation directory so later replacements do not overwrite them:

New-Item -ItemType Directory -Force "C:\Tools\mytool-backup" | Out-Null
Copy-Item "C:\Tools\mytool\mytool.exe" "C:\Tools\mytool-backup\mytool-old.exe"
Copy-Item -Recurse "$env:USERPROFILE\.mytool" "$env:USERPROFILE\mytool-config-backup"

If the installation directory is in a protected path such as C:\Program Files, replacing files requires administrator privileges. Use administrator rights only for the replacement step. Perform downloading, extraction, and verification as a standard user to limit the effect of mistakes.

Get the new version and verify its integrity

Download the archive that matches your system architecture from the tool’s official release page. On 64-bit Windows, choose the package labeled x64 or amd64. A download source can be considered official when its domain matches the project homepage, the release page is maintained by the project maintainers, and the page lists the version number and a checksum.

If the official site is slow, you can use a mirror or a system proxy. A mirror only handles file transfer, so it is not a trusted source. Verify any file obtained from a mirror against the SHA256 value published on the official release page. If the official page does not publish a checksum, do not use the file.

After downloading, compute the file’s hash and compare it character by character with the value on the official page:

Get-FileHash -Algorithm SHA256 .\mytool-windows-x64.zip

In cmd, use certutil -hashfile mytool-windows-x64.zip SHA256. If the tool publishes a code signature, you can also check it:

Get-AuthenticodeSignature .\mytool.exe | Format-List Status, SignerCertificate

The Status value should be Valid, and the signer should be the project maintainer. If the hashes do not match, discard the file and download it again. Extract the archive to a temporary directory, such as C:\Temp\mytool-new, and not directly into the installation directory that is in use.

Locate the current installation path

In cmd, use where.exe to find the executable:

where.exe mytool

In PowerShell, where is an alias for Where-Object, so where mytool does not return the right result. Use where.exe instead, or use Get-Command:

Get-Command mytool | Select-Object -ExpandProperty Source

If the output contains multiple paths, the system has more than one copy. Record every path and determine which one is the version actually being called. You can also open the Details tab in Task Manager to check the path of the running process and confirm that it matches the results above.

To check PATH, review the user-level and system-level settings separately:

[Environment]::GetEnvironmentVariable('Path', 'User') -split ';'
[Environment]::GetEnvironmentVariable('Path', 'Machine') -split ';'

Stop processes and replace the binary

Before replacing the file, end all related instances, including terminal windows, IDE-embedded sessions, and background daemon processes. Check whether any processes are running:

Get-Process mytool -ErrorAction SilentlyContinue

Once you confirm that no sessions need to be kept, stop the processes:

Stop-Process -Name mytool -Force

After stopping them, check again and confirm that the output is empty. If processes are still running, the file is locked, and the copy will fail with a “file is in use” error. Do not force-delete the file. Find the process that holds it first.

Copy the newly extracted executable over the original path:

Copy-Item "C:\Temp\mytool-new\mytool.exe" "C:\Tools\mytool\mytool.exe" -Force

Verify the version and run a smoke test

Open a new terminal window so that no old session has cached the previous path. Run the version check:

mytool --version

The version number in the output should match the official release page. If the version number has not changed, PATH probably still points to the old file. Run where.exe mytool and check the first path in the list. Then correct PATH or delete the old copy.

Next, run a smoke test: start the tool, execute a simple command, and check that the output is normal. If the tool writes logs to a logs subdirectory of the configuration directory, view the most recent log with this command:

Get-Content "$env:USERPROFILE\.mytool\logs\latest.log" -Tail 50

The log file name depends on the actual tool. If the tool fails to start, roll back with this command:

Copy-Item "C:\Tools\mytool-backup\mytool-old.exe" "C:\Tools\mytool\mytool.exe" -Force

After rolling back, open a new terminal, run the version check again, and confirm that the old version is restored.

Completely uninstall: remove files, configuration, cache, and PATH

Stop all processes before uninstalling. Deletion cannot be undone, so move the items to a backup directory first, and empty that backup only after you confirm the tool uninstalled correctly. Running Remove-Item -Recurse -Force permanently deletes the configuration and history, so avoid it.

Handle the following items in order:

1. The executable and supporting files in the installation directory.
2. The user configuration directory, such as %USERPROFILE%\.mytool.
3. The cache directory. A common location is %LOCALAPPDATA%\mytool\cache, but check the tool’s documentation for the exact path.
4. The tool’s paths in the user-level and system-level PATH.

For example, move the configuration into a backup location instead of deleting it directly:

Move-Item "$env:USERPROFILE\.mytool" "$env:USERPROFILE\mytool-removed-$(Get-Date -Format yyyyMMdd)"

To edit PATH, use the environment variables dialog in System Properties. If you edit it with a script, first export the current value as a backup, then write the new value, and confirm that no other entries were lost.

If the tool wrote to the registry, first confirm that the key exists, then export a backup before deleting it:

reg query "HKCU\Software\mytool"
reg export "HKCU\Software\mytool" "%USERPROFILE%\mytool-registry-backup.reg"
reg delete "HKCU\Software\mytool" /f

If the key does not exist, reg query returns an error. This is expected, and no action is needed. Do not delete registry keys whose purpose you cannot confirm.

After uninstalling, open a new terminal and run the original command. The system should report that the command cannot be found. Then run where.exe mytool to confirm that no paths remain, and check the Start menu for leftover shortcuts.

Residual checks

Leftovers usually fall into three categories. The first is an old path in PATH, which keeps calling the old version after an update. The second is multiple copies coexisting, and where.exe lists every match. The third is a mismatch between the configuration and the binary version, which shows up as startup failures or parameter errors. The location steps in this guide find the first two. For the third, check the logs and use the backup to roll back.

Switching between multiple versions (optional)

If you switch versions often, you can place each version in its own directory, such as C:\Tools\mytool\1.2.0 and C:\Tools\mytool\1.3.0, and use a symbolic link to point to the current version:

New-Item -ItemType SymbolicLink -Path "C:\Tools\bin\mytool.exe" -Target "C:\Tools\mytool\1.3.0\mytool.exe"

Creating a symbolic link requires Developer Mode or an administrator session. To switch versions, point the link to the target file again. You do not need to overwrite the original file.

Risk checklist

Confirm each item before and after the operation:

• The executable and configuration directory are backed up, and the backups are outside the installation directory.
• The package hash matches the official release page, and the mirror was used only for transfer.
• All related processes are stopped, and Get-Process returns no output.
• After replacement, the version number is correct in a new terminal, and the first path from where.exe is the expected file.
• No old paths remain in PATH, and registry changes were exported as backups first.
• Deleted configuration and cache files were moved to a backup, and you will clean them up after confirming the tool works.
• If the tool fails to start, you rolled back from the backup and verified the version number again.

Following this checklist lets you verify each step of an update or uninstall and revert at any point, which avoids configuration loss and version confusion.