WinGet 1.28.240: Claude Code May Not Upgrade or Uninstall

Admins can approve Claude Code through winget install Anthropic.ClaudeCode, but they should not treat a successful install as proof that the device is patchable, inventoried, or cleanly removable. Until the organization has tested the package on its deployed App Installer version, Claude Code and comparable portable AI CLIs should remain under an explicit reconciliation control that verifies install, list, upgrade, and uninstall behavior.
Anthropic’s own documentation makes the operational boundary clear: a WinGet installation of Claude Code does not auto-update by default, and its documented manual update path is winget upgrade Anthropic.ClaudeCode. That is manageable for an individual developer. For IT, however, the relevant question is not whether the first install works; it is whether WinGet’s record of that install remains trustworthy through the package’s lifecycle.

The practical approval test should happen before broad deployment​

A controlled pilot should test every approved portable package on the same App Installer version deployed to production endpoints. Do not rely on a package’s manifest, a successful terminal return code, or the appearance of a claude command in PATH as the sole acceptance criteria.
Use a disposable test device or VM and document the output from each of these steps:

1. Install Claude Code with winget install Anthropic.ClaudeCode.
2. Confirm that WinGet can enumerate the installed package with winget list Anthropic.ClaudeCode.
3. Run the documented update command, winget upgrade Anthropic.ClaudeCode, and confirm that WinGet can evaluate and, where applicable, perform the upgrade.
4. Remove the package with winget uninstall Anthropic.ClaudeCode.
5. Run winget list Anthropic.ClaudeCode again and confirm that the package is no longer reported.
6. Separately verify the operational result: the expected executable, PATH entry, or symlink should not leave a second Claude installation unexpectedly taking precedence.

This is not busywork. A May 3, 2026 WinGet issue reported that a portable Claude Code installation completed successfully but did not appear in winget list and could not subsequently be upgraded or uninstalled. The report identified WinGet 1.28.240. It was closed on May 18, 2026 after inactivity, without a linked fix.
That sequence is the important part for administrators. Install succeeded; lifecycle management reportedly did not.

---

Claude Code is a useful test case, not an isolated indictment​

Anthropic documents an environment setting, CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1, that can configure Claude Code to invoke package-manager updates in the background. Anthropic also warns that a Windows executable lock can cause a WinGet upgrade to fail while Claude Code is running.
That is a normal Windows deployment concern: an executable in use can block replacement. But it also reveals why package ownership must be clear. If one team expects Claude Code to update itself, another expects WinGet to update it during a maintenance window, and the inventory system cannot reliably see the installed package, the endpoint may be technically functional while administratively opaque.
The recommendation is not to ban Claude Code because it is an AI CLI. The recommendation is to treat it as a portable application with a distinct management profile. Portable installs can involve executable placement, PATH exposure, symlink behavior, and tracking data that require more validation than a conventional installer entry.
WindowsForum’s ongoing discussion of curated WinGet upgrades on managed PCs points in the same direction: winget upgrade --all is useful, but it is not a substitute for an approved-package policy and verified ownership model. A machine-wide command cannot repair uncertainty about whether WinGet actually recognizes a particular portable install.

The shared claude.exe name still matters, even if it is not the tracking failure​

The Claude Code report also raised concern over the Claude desktop application and Claude Code sharing the claude.exe name. Microsoft’s WinGet maintainer said that shared executable name is not a portable-package tracking-key collision. WinGet portable tracking uses a registry key derived from the package identifier, rather than the command name.
That distinction matters. It means administrators should not assume the shared executable name explains an inventory gap. The reported tracking behavior and a command-name conflict are different problems.
But the maintainer also acknowledged the practical risk: shared names can create a PATH or symlink conflict. In real environments, that can be just as disruptive as a broken inventory record. A script, terminal session, IDE task, or help-desk runbook may invoke claude and receive a different executable than the operator expected.
That creates two separate controls:

• WinGet must be able to track the package by its identifier through install, update, and removal.
• Endpoint configuration must make it clear which claude.exe resolves first when users or automation call the command.

The first is an inventory and patch-management control. The second is an execution-path control. Passing one does not demonstrate that the other is safe.

---

Reconciliation should be a required compensating control​

For a portable AI CLI, reconciliation means comparing what the package manager says with what the endpoint actually exposes. If winget install Anthropic.ClaudeCode reports success but winget list Anthropic.ClaudeCode does not show the package, that endpoint should be treated as an exception rather than silently accepted into the managed estate.
A practical control can be simple:

• Record the exact App Installer and WinGet version used during validation and deployment.
• Retain the install result and the matching winget list result for approved packages.
• Run a scheduled or post-deployment check that identifies devices where the expected package is absent from WinGet’s list.
• Escalate any device where an upgrade or uninstall command cannot resolve the package that was previously installed.
• Check command resolution where another Claude product may place a claude.exe on PATH.

The point is not to build a second package-management platform around WinGet. It is to avoid using a single successful installation event as evidence of a managed state.
This is especially relevant for organizations adopting developer-facing tools quickly. AI coding assistants often reach endpoints through individual developer demand, and a fast command-line install is one of WinGet’s strengths. The same convenience can bypass the slow but necessary questions: Who owns updates? What records the installed state? What happens when the tool is running during a patch attempt? Can the organization remove it without manually hunting down files and path entries?

WinGet 1.29 offers encouraging work, not a retroactive all-clear​

WinGet 1.29 release notes include work related to portable-install ARP correlation and tracking-database healing. Those changes are relevant to the category of failure reported with Claude Code, and they are worth testing.
They are not, however, proof that the May report is fixed. The closed issue did not link a fix, and the available record does not establish that either of those 1.29 changes resolves the reported Claude Code scenario. Administrators should resist the tempting shortcut of reading “tracking-database healing” as a blanket guarantee.
This is where version-specific acceptance testing matters. An organization may run an App Installer version different from the one used in the reported issue and different again from the version containing the newer work. The only defensible conclusion is local: test the approved package on the version actually deployed to users, then retain the result.
That mindset is also healthier than pinning the entire discussion on Anthropic. Claude Code is simply a visible example because its vendor documents WinGet installation and manual upgrading, while a public report exposed the gap between a completed portable install and reliable lifecycle control.

---

Background updating can complicate the ownership model​

The CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1 setting deserves a deliberate policy decision. It may be appropriate for an unmanaged developer workstation, but it can undermine maintenance-window discipline if an organization expects updates to be centrally initiated and logged.
There is also the executable-lock warning from Anthropic. If Claude Code is active when WinGet attempts an upgrade, the update can fail. A management process that enables background updating must therefore decide whether it will ask users to close the tool, retry later, or rely on a separate maintenance workflow.
The conservative enterprise posture is to select one accountable update route per package. Either Claude Code is permitted to request package-manager updates under a defined policy, or updates are initiated through the organization’s managed WinGet process. Mixing both without reconciliation creates ambiguity when version state drifts.

Frequently Asked Questions​

Should organizations block Claude Code from WinGet?​

Not necessarily. Claude Code can be approved when it passes lifecycle testing on the organization’s deployed App Installer version and has a documented reconciliation process. The concern is management reliability, not that the tool is uniquely unsuitable.

Does winget install guarantee that winget upgrade and winget uninstall will work later?​

No. The May 2026 Claude Code report described a successful portable install that was absent from winget list and could not be upgraded or uninstalled on WinGet 1.28.240.

Does the shared claude.exe name break WinGet tracking?​

Microsoft’s WinGet maintainer said no: portable tracking uses a registry key derived from the package identifier. The shared name can still create a PATH or symlink conflict that affects which executable runs.

Is WinGet 1.29 confirmed to fix the Claude Code report?​

No. Its release notes mention portable-install ARP correlation and tracking-database healing, but the closed Claude Code issue did not establish that those changes resolve the reported behavior.
The next sensible milestone is not a broad approval or a blanket prohibition. It is a versioned pilot: install, list, upgrade, uninstall, and command-resolution testing for Claude Code on the App Installer version actually in service. If all five behaviors hold, WinGet can remain the delivery mechanism; if any fail, the package needs reconciliation or a different management path before it enters the patch inventory.

---

References​

1. Primary source: learn.microsoft.com
   
   

   uninstall Command | Microsoft Learn

   uninstalls the specified application.

   learn.microsoft.com
2. Independent coverage: support.claude.com
   
   

   Claude Code user FAQ | Claude Help Center

   support.claude.com
3. Independent coverage: code.claude.com
   
   

   Advanced setup - Claude Code Docs

   System requirements, platform-specific installation, version management, and uninstallation for Claude Code.

   code.claude.com
4. Independent coverage: github.com
   
   

   GitHub - microsoft/winget-cli: WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface). · GitHub

   WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface). - microsoft/winget-cli

   github.com
5. Primary source: WindowsForum
   
   

   WinApp: Microsoft cross platform CLI to accelerate Windows apps | Windows Forum

   Microsoft has quietly rolled out a new developer tool that aims to remove much of the friction that has kept many cross‑platform teams from building...

   windowsforum.com