[BUG] Cowork "Outputs" panel cannot open or save generated files on Windows MSIX (v1.28929.0.0)

Summary

In the Cowork Outputs panel on Claude Desktop for Windows (MSIX), files produced during a session cannot be opened or saved. Clicking a file either does nothing, shows a toast reading "Nao foi possivel abrir o arquivo." ("Unable to open the file"), or reports that the file cannot be saved.

This is distinct from the known update file-lock bug (#76357, #75337, #45400) — it reproduces on a clean install of the current version with CoworkVMService healthy.

Environment

• Claude Desktop, Windows 11 x64, MSIX install: C:\Program Files\WindowsApps\Claude_1.28929.0.0_x64__pzs8sxrjxfjjc
• Get-AppxPackage Claude -> 1.28929.0.0
• Display language: Portuguese (Brazil)
• PowerShell 7.6.4
• Plan: Max. Cowork mode, session attached to a Project
• Get-Service CoworkVMService -> Running at the time of failure

Steps to reproduce

1. In a Cowork session, ask Claude to generate a file (two .ps1 scripts, in my case).
2. The files appear in the right-hand Outputs panel.
3. Click a file.

Expected

The file downloads, a save dialog appears, or it opens in a preview.

Actual

One of three outcomes: nothing happens at all; a toast reads "Nao foi possivel abrir o arquivo."; or the app reports it cannot save the file.

In one case the file content rendered correctly in the preview pane while the same toast error appeared over it — suggesting the content is reachable and the failure is in the local file-handoff step, not in retrieving the artifact.

Reproduced both while the app was in a half-updated state (pending "Relaunch to update") and after a clean reinstall on 1.28929.0.0 with the service Running, so the pending-update state is not the cause.

Workaround

Have Claude emit the file as text in chat, then write it to disk with a PowerShell here-string + Set-Content. This defeats the purpose of the Outputs panel for non-technical users.

Related: extra diagnostics for the update file-lock bug (#76357 / #75337)

While getting to this state I collected details that may help those issues:

• The lock is held by CoworkVMService (cowork-svc.exe) plus Claude.exe / chrome-native-host.exe from the package dir. Stopping the service and killing only processes whose ExecutablePath is under %ProgramFiles%\WindowsApps\Claude_* releases it without a reboot, if done before the relaunch.
• After the failure, the package enters deferred registration and killing processes no longer helps. Even a reboot left the app unlaunchable: the failed Claude_1.28929.0.0_... directory had been rolled back and no longer existed, while Get-AppxPackage still reported 1.26832.0.0. Only uninstall -> reboot -> fresh install from claude.ai/download recovered it.
• In that broken state other Store/MSIX apps also degraded (Snipping Tool stopped working), pointing at the Windows package deployment service being wedged.
• For repair tooling / support snippets: IsInRole("Administrators") returns False on non-English Windows even when elevated. The built-in-role enum must be used instead, or the check silently misleads users on localized systems.

Requested fixes

1. Quiesce CoworkVMService and confirm package processes exited before applying the MSIX update; restart after.
2. Clean up superseded WindowsApps\Claude_* folders on successful update.
3. Replace the raw sharing-violation dialog with an actionable message ("sign out to finish updating").
4. Investigate the Outputs panel open/save path on Windows, including the preview-renders-but-handoff-fails case.