[BUG] Windows MSIX: in-app updater loops "Downloading update…" forever (self-update disabled on MSIX), and updated package requests camera access on first launch

Environment

• Claude Desktop (Windows 11 Pro, 10.0.26200), MSIX install (Claude_pzs8sxrjxfjjc, WindowsApps)
• Observed on 1.24012.1.0, resolved by manually installing 1.24012.9.0

Bug 1: perpetual "Downloading update…" spinner on MSIX installs

The sidebar shows "Downloading update…" indefinitely. Quitting from the tray and relaunching just restarts the same loop. main.log shows why:

18:12:59 [CCD-autoupdate] Disabled: MSIX install
18:12:59 [updater] MSIX detected: windowsStore=true, appPathMatch=true, source=windowsStore
18:13:34 [updater] Found an update, downloading
   (user quits from tray, relaunches)
18:19:17 [CCD-autoupdate] Disabled: MSIX install
18:19:25 [updater] Found an update, downloading

The updater checks the update endpoint, finds a newer version, and flips the UI into "downloading" — but self-update is (correctly) disabled for MSIX installs, so the download can never be applied. The result is a UI that permanently claims to be downloading an update it cannot install, on every launch. Meanwhile the Microsoft Store had not yet been offered the new package (staged rollout), so there was no user-visible path to the update; running the downloaded Claude Setup.exe (which installs the same MSIX package family) is what finally moved 1.24012.1.0 → 1.24012.9.0.

Expected: on MSIX installs, either don't enter the downloading state at all, or show "Update available — install via <channel>" instead of a spinner that never completes.

Related but distinct from the MSIX update-failure cluster (#76357, #77421, #73505): those are about updates failing to apply; this is the updater UI promising a download it is architecturally unable to apply.

Bug 2: updated package requests camera access on first launch

On first launch after the 1.24012.9.0 update, Windows showed a camera consent prompt for Claude, and the consent store now shows webcam\Claude_pzs8sxrjxfjjc = Allow. Nothing in the app plausibly needs the camera; voice dictation needs only the microphone, and the AppxManifest doesn't even declare a webcam capability. It appears the media layer enumerates all capture devices (rather than audio-input only), which triggers the OS camera consent. Requesting camera access an app doesn't use erodes exactly the trust an agentic desktop app needs.

Expected: device enumeration scoped to audio inputs; no camera consent prompt unless a camera feature actually exists.

🤖 Generated with Claude Code