If you're not going to give Claude access to anything on your machine, why are you using Desktop instead of web chat? (Real question, I don't use these much!)
At least in a corporate environment, Claude Desktop is a pretty decent compromise. Preconfigured internally deployed MCP servers and third-party connectors make many of the necessary integrations relatively easy to control.
I use Claude Code CLI myself (inside a VM, to isolate it from the host) for >90% of my needs. For the remaining fraction - email scours, cloud drive searches, other third-party connections - the desktop application is surprisingly decent. I don't even have more than half a dozen connectors enabled. In the VM I have separate, personally managed access tokens available for various third-party services. Wouldn't really try to maintain more than 5-6, otherwise it gets too confusing. [ß]
The desktop application mostly Just Works[tm] with SSO. At least when M365 doesn't suffer from their 4-times-a-day auth outage.
ß: A lot of APIs and authentication systems were designed in the stone age. You either need a 1:1 permissioned access token that can do horrendous damage, or you deal with ultra-granular, confusing and ill-designed scoping jungle where nothing makes sense. Atlassian, I'm looking at you especially. At least an MCP server, provisioned with a reasonably done service account, doesn't have all of your powers to get things wrong with.
The cloud instance certainly runs a full mitm proxy. There are complications for that when dealing with logging, but maybe on the desktop it doesn't log, just running a permissions engine.
I do use Claude Cowork and hence the VM is important, but I also leave the desktop app running all the time since I have many scheduled tasks at different times. The thing is that the VM could shutdown after being idle for some amount of time and then fire back up when you are ready to use it.
Shouldn't it get swapped out of RAM if it's not being used for a long time? My understanding was that modern memory management is very good at this, there's no need to be shutting idle things down and starting them up all the time. I could be wrong.
This whole thing seems kind of silly to me I must admit. It seems obvious that Claude Desktop needs a VM for security for the majority of it's actual real world use. VM's take up memory, yeah. Them's the breaks. If other competitors have managed to provide as good (or ideally better) security scenario with less RAM, that would be interesting, but just complaining about it seems weird and uninformed to me.
There's such a spectrum between "give it everything" and "give it nothing". Imagine you just want to use it to code and want to make sure any commands it runs doesn't mess up your actual machine.
I use Claude Code CLI myself (inside a VM, to isolate it from the host) for >90% of my needs. For the remaining fraction - email scours, cloud drive searches, other third-party connections - the desktop application is surprisingly decent. I don't even have more than half a dozen connectors enabled. In the VM I have separate, personally managed access tokens available for various third-party services. Wouldn't really try to maintain more than 5-6, otherwise it gets too confusing. [ß]
The desktop application mostly Just Works[tm] with SSO. At least when M365 doesn't suffer from their 4-times-a-day auth outage.
ß: A lot of APIs and authentication systems were designed in the stone age. You either need a 1:1 permissioned access token that can do horrendous damage, or you deal with ultra-granular, confusing and ill-designed scoping jungle where nothing makes sense. Atlassian, I'm looking at you especially. At least an MCP server, provisioned with a reasonably done service account, doesn't have all of your powers to get things wrong with.