Three failures, one root cause
Look at what people actually report about desktop AI apps (Claude Desktop is the well-documented example, but it's the category, not one vendor): the app breaks itself on Windows, the GitHub/file integration says "connected" but the file tree is empty, and after an update your chat history seems gone. Three unrelated-looking complaints — but they share a root: a hosted, sandboxed app that only reaches your machine through narrow bridges it doesn't fully control.
The pattern
| What you see | What's really going on | Why local doesn't hit it |
|---|---|---|
| Install self-corrupts / "this app can't open" | MSIX sandbox + a bundled DLL that Windows blocks; the package flags itself broken | A normal (non-MSIX) process has no signing-level check to trip over |
| Integration "connected" but does nothing | The connector can list a repo but can't actually read files through the sandbox bridge | A local agent reads your real files and folders directly — no bridge to fail |
| Sessions / login wiped on update | New build uses a different data dir than the old sandboxed one | Local data lives in one folder you own; updates don't move it |
1. The install that corrupts itself
On Windows, a Store/MSIX build that bundles a software-rendering DLL gets that DLL blocked by Code Integrity, the render process crashes, and the whole signed package flags itself as needing repair. Repair only resets the clock. It's not a bad download — it's the packaging. A local app that installs to a normal folder never faces that signing-level enforcement, so there's nothing to self-corrupt.
2. The integration that's "connected" but empty
People connect a GitHub repo, the app says connected, and then the file tree is empty — adding a repo just drops its URL into the chat as text, and prompts referencing it can't reach the files. That's what happens when access goes through a narrow connector rather than the filesystem. A local agent doesn't need a connector to see your code: it reads the actual files and folders on your disk, the same way you do in a terminal. There's no bridge to be "connected but empty."
3. The history that disappears
After an update, your sessions look wiped. Usually they're not deleted — the new build just points at a different data directory than the old sandboxed one, so it can't see the old history. When your data lives in one plain folder you own, an update is just a new binary reading the same folder. Nothing to lose track of.
What a local agent does differently
Runs as a normal process
No MSIX sandbox, no bundled-DLL signing check, so no self-corruption class of bug.
Reads your real filesystem
It works with the files and folders on your machine directly — no connector that can be 'connected but empty.'
Owns its data
Config and history sit in one folder you control; updates don't strand them.
Bring your own model
Not bound to one account/plan, so an auth or quota problem on one provider doesn't lock you out.
The honest tradeoff
A local agent isn't magic — you point it at a model (your own key, or a local model), and you're responsible for that setup. What you get in return is that a whole category of "the app broke itself again" problems simply doesn't exist. If you've been fighting your desktop AI app more than you've been using it, that tradeoff is usually worth it.
FAQ
Why does Claude Desktop (or similar apps) keep breaking on Windows?
Most often it's the packaging: a Store/MSIX build bundles a DLL that Windows Code Integrity blocks, which crashes the render process and flags the package as broken. Repair only holds briefly because it doesn't remove the trigger.
My AI app says the GitHub/file integration is connected but the files don't show up. Why?
Access is going through a narrow connector that can list a repo but can't read files through the sandbox. A local agent avoids this by reading your actual filesystem directly instead of relying on a connector.
Did an update really delete my chat history?
Usually no — the new build just uses a different data directory than the old sandboxed one, so it can't see the old history. It's often still there in the old folder.
What's the downside of a local agent?
You have to bring a model (your own API key or a local model) and manage that setup yourself. In exchange, the whole 'the app self-corrupts / integration is broken / history vanished' category doesn't apply.