Windows desktop app: projects, memory, and sandboxing are invisible or missing - field report from shipping a real product through it

Context: Author/developer on Windows 11, built and deployed a live browser game over several multi-hour sessions in the desktop app. Heavy Chat + Cowork user (also built over a dozen sites, apps, and tools with chat and cowork) — that's the user onramp, and its paradigms don't transfer.

Projects aren't top-level. Chat and Cowork put Projects in the left sidebar; Code hides them behind a filter next to Recent Chats. I discovered Code had projects on day three, when the model told me.

Project memory has no UI at all. Code maintains per-project persistent memory files that load every session — a headline feature I only learned exists because the model mentioned it, and I still can't view it anywhere in the app. (It's on disk at ~/.claude/projects/<folder>/memory/, but I only know that after Claude told me when I started bitching.)

Windows permission storm. No OS sandbox on Windows means every PowerShell call prompts. A simple autonomous task took 22 hours because it accumulated dozens of approval clicks.

"Always allow" saves exact strings. Approvals write verbatim-command rules to settings.local.json (git add css\style.css), which generalize to nothing — so clicking allow hundreds of times builds almost no lasting permission. Users can't discover that pattern rules exist.

The environment picker (Local / Cloud / Remote Control / SSH) offers no WSL or Docker option. WSL2 would inherit the Linux sandbox while working on real local folders; a container option would offer Cowork-grade guardrails. The remote-execution plumbing clearly already exists, and yes I can set it up myself, but it adds friction.

Windows has native sandboxing primitives (AppContainer, restricted tokens, job objects, scoped users + ACLs) that Code doesn't use. Windows parity is an investment choice that Anthropic seems to be choosing not to make, not an OS limitation.

Impact: I shipped the first 1/3 of the game, but I spent the last day seriously evaluating abandoning Code for Cowork purely over friction — while sitting on top of capabilities (projects, memory, pattern allowlists) that would have solved my complaints, invisibly.

Code does have some generally useful features that chat and cowork don't have, but to be honest the amount of frustration I've experienced having tasks take hours or days longer than they should have because an "allow" prompt was sitting there unclicked has made me seriously reconsider how I use Claude.

Having used cowork to build everything from web sites to windows services to android apps, it is literally easier to build an MCP server to handle inconveniences around using cowork than it is to use code.