To keep Claude Code out of your .env, permissions.deny (Read(./.env)) stops the honest mistakes — the Read tool and a literal cat .env — but it is a string match, so node -e readFileSync('.env') or a filename assembled from fragments reads right through. A PreToolUse hook catches the script but still falls to the assembled name. Only the sandbox (sandbox.enabled with sandbox.filesystem.denyRead, Claude Code v2.1.187+) blocks every bypass at the OS level with EPERM. Ranking: sandbox > hook > deny. deny is a mistake-guard, not a security boundary.
Claude Cowork sees only the folder you connect — not your whole computer. Inside that folder it can read, edit, and delete (deletion always asks first), but it can't reach files outside it or your network; the code runs in an isolated, temporary environment on Anthropic's servers. So the answer to 'is my data safe?' comes down to one choice: which folder you hand over. Connect a subfolder with only the files a task needs, keep approval prompts on, and remember that a document Claude reads can carry hidden instructions of its own.
If you've connected MCP servers (a notetaker, Gmail, Drive) to Claude Code, check three layers: run claude mcp list to see what's connected (reach), set settings.json permissions so risky tools are read-only or denied (scope — deny wins over allow), and keep the approval prompt on (gate). And remember the vector nobody mentions: text your notetaker pulls in — a meeting transcript — can itself carry instructions the agent will try to follow. Claude Code's own docs warn to trust a server before connecting it.