[DOCS] Windows desktop app's idle-timeout auto-restart to apply updates ("stealth update") is undocumented — release notes silent, controls only in the enterprise article

Documentation Type

Missing documentation (feature not documented)

Documentation Location

https://support.claude.com/en/articles/12138966-release-notes (also relevant: https://support.claude.com/en/articles/12622667-enterprise-configuration-for-claude-desktop, https://support.claude.com/en/articles/10065433-install-claude-desktop)

Section/Topic

Claude Desktop (Windows MSIX) auto-update behavior — idle-timeout forced restart

Current Documentation

The release notes page (entries Sept 2025 – Aug 2026) carries feature-level entries for the desktop app but nothing about update mechanics. The only documentation of automatic update application at all is in the enterprise configuration article: disableAutoUpdates (DWord, registry Policies\Claude) and autoUpdaterEnforcementHours (1–72, default 72 — "Hours before forcefully restarting Claude to apply a prepared update"). No user-facing doc mentions that the app restarts itself to apply updates, and there is no in-app setting.

What's Wrong or Missing?

Observed on 2026-08-11 (Claude Desktop 1.26832.0 → 1.28929.0, Windows 11, MSIX Claude_pzs8sxrjxfjjc):

• 6:53 PM ET — updater staged 1.28929.0 while the app was running ([updater] Update downloaded and ready to install); AppX deferred registration because the app was in use.
• 7:03 PM ET — with nobody at the machine, main.log shows: [stealth-update] Triggering stealth update after idle timeout → window z-order and navigation saved → beforeQuitForUpdate handler fired → AppX RegisterByPackageFamilyName with ForceApplicationShutdownOption → app force-closed, updated, relaunched, and restored its state. Ten minutes after staging.

Why this needs documenting: an app relaunch boots every configured MCP server, and credentialed MCP servers (e.g., Microsoft Graph servers using client-credential certificates, such as Lokka) re-authenticate immediately on startup. In our case service-principal sign-ins were generated with zero user presence, which tripped the sign-in alerting we run on our automation identities. Any org that monitors authentication on its automation credentials will see unexplained sign-ins that correlate to nothing a human did.

This appears to be new, or newly enabled: on this same machine the previous update (staged Aug 6) sat for three days across multiple idle nights and only applied at a user-initiated restart ~71 hours later, and the idle-timeout path fired for the first time ever on Aug 11. The updater is feature-flag-driven ([updater] Using GrowthBook check_interval_ticks=1 (default 4)), so this may be a server-side cohort rollout rather than a client change.

Questions:

1. Is the idle-timeout "stealth update" restart a recent change (client version and/or server-side flag)?
2. Does autoUpdaterEnforcementHours bound or configure the idle-timeout path, or is that a separate mechanism?
3. Is there any supported per-user opt-out besides the registry policy documented in the enterprise article?

Suggested Improvement

1. A release-notes entry whenever update mechanics change (not just features) — especially for changes that could generate authentication events with no user present.
2. Document the auto-restart behavior and the disableAutoUpdates / autoUpdaterEnforcementHours policies in user-facing install/settings docs, not only the enterprise article.
3. Ideally (a product ask beyond docs): an in-app toggle mirroring disableAutoUpdates, so opting out doesn't require registry edits casual users won't make.

Impact

Medium - Makes feature difficult to understand

Additional Context

Related: #66075 (June 2026 — unattended MSIX force-restart bringing a tray-resident app to the foreground; closed not-planned). This report is the documentation-gap angle: the behavior may well be working as designed, but it's documented nowhere a non-enterprise user would look, and the release-notes channel that could have announced it is active but silent on update mechanics. Environment: Claude Desktop 1.28929.0.0 (MSIX), Windows 11 Pro build 26200.