I've been building an endpoint security sensor for Windows, the kind of thing that watches process activity, file writes, and network connections in real time and flags patterns that look like malware. One of the rules I added recently watches for a specific, well known credential theft technique: a process that isn't a browser reaching into a browser's cookie and password files. Real infostealers do this constantly. It's MITRE technique T1555.003, and it's one of the first things a lot of commodity malware does once it's on a machine.
A few hours after turning that rule on, it fired. Critical severity. The process reading Edge's cookie database wasn't some unknown binary. It was claude.exe, the Claude desktop app.
My first guess was a bug in my own sensor, and there was one: the rule's exclusion list expected process names with ".exe" on the end, but the event stream that feeds it strips the extension, so the rule's own attempt to exclude real browsers from the check had never worked in the first place. I fixed that. But once I fixed it, a separate and real claude.exe alert stayed put, and it kept firing every few minutes.
So I went looking at what claude.exe was actually doing, file by file. It was writing Chromium metrics files directly into Edge's real profile folder. It was registering service workers and caching scripts under Edge's "Default" profile, the same profile my actual browser uses. And yes, it was touching the real cookies file too.
Here's what's going on. Claude Desktop has a feature called Cowork that can browse the web on your behalf as part of a task. To do that, it embeds Microsoft's WebView2 control, which is Edge's rendering engine packaged as a library you can drop into any Windows app instead of a standalone browser. Apps that use WebView2 almost always get their own private folder for cookies and cache, completely separate from whatever browser is installed on the machine. That separation is the entire reason to embed a rendering engine instead of just shelling out to a real browser.
On this machine, that separation isn't happening. The copy of WebView2 running inside Claude Desktop is writing straight into the same profile folder my actual Edge browser uses. Same cookies, same session storage, same cache.
That matters more than it sounds like. If Claude's agent goes and looks something up on the web, it isn't browsing as a stranger. It's carrying my real Edge session with it, so any site I'm already logged into in Edge, the agent is effectively logged into as well. Going the other direction, whatever it looks up leaves traces in my actual browsing history and cache, not some disposable sandbox.
None of this is malicious. It's a real feature doing exactly what it's supposed to do on the browsing side, just apparently pointed at the wrong data folder. But it's exactly the kind of thing a security sensor is supposed to catch: something quietly reading and writing another app's credential store, whether the reason turns out to be theft or a default nobody looked at closely.
I haven't found this documented anywhere, and I don't know if it's specific to this machine or
true for every install of Claude Desktop with Cowork's web feature turned on. If you run Claude
Desktop and want to check for yourself, watch whether claude.exe touches
%LOCALAPPDATA%\Microsoft\Edge\User Data\Default\Network\Cookies.
The rule that caught this, VK-C002, is one of about two dozen in vk-ai-sensor watching for the kinds of things attackers actually do on a Windows box.