The Microsoft Store opening by itself days after a Claude install almost always traces back to a broken claude:// protocol handler. In split-account Windows setups the MSIX registers under the admin profile, so your session cannot resolve the link and Windows offers the Store. Here is the cause and the fix.
Claude Code lives in your terminal. Claude for Chrome lives in your browser. They do not share context. So your Code session writes a self-contained prompt your for-Chrome session can run, and the browser job gets done. Plus how the native paths work on macOS, Windows, and Edge today.
Drop a CLAUDE.md at the root of a SharePoint site and nothing propagates. Each Claude product reads CLAUDE.md a different way. Four parallel loaders, all pulling from one canonical file, are what makes a single source of truth actually land in every session across Claude Code, Desktop, web, and Cowork.
Claude Desktop's Microsoft 365 connector reads email body but not attachments. Three workarounds exist. Two are blocked in most secure tenants by design. The path that lasts is registering your own Entra ID app with Mail.Read delegated. Here is the architecture, the failure modes, and the PowerShell that runs.
Claude now has three distinct modes and most companies are using the wrong one. Chat is for quick conversations. Cowork is the autonomous agent with 50+ connectors that handles everything except code. Code is the terminal-native developer tool. The right choice depends on what you are trying to get done, not which sounds fanciest.
Getting Claude Desktop installed is the easy part. Keeping hundreds of enterprise machines on the same version when Anthropic ships weekly updates and the auto-updater silently fails on managed endpoints is the problem nobody warns you about.
The standard Claude Desktop installer fails on enterprise Windows machines managed by Intune. Developer Mode is not the fix. Deploy the signed MSIX package through Intune as a Line of Business app to bypass all three failure modes without weakening security.