Claude Code Projects Security: What the Beta Hides

The same week Anthropic relaunched Claude Code Projects as a multi-agent cloud orchestrator, a disclosed vulnerability called Plugin4Shell showed that a pinned commit hash — the thing teams trust to lock a plugin to reviewed code — could be silently bypassed by a attacker-controlled branch name. That pairing is the whole story of Claude Code Projects security right now: the platform is shipping genuinely useful security tooling at the Enterprise tier while the client-side plumbing underneath it keeps springing leaks. If you’re evaluating whether to let parallel cloud threads loose on your repositories, the marketing page won’t tell you where the bodies are buried. The changelogs will.

Here’s what the evidence actually shows, layer by layer.

What changed in Projects, and why does it expand the attack surface?

The September 17 redesign turned Projects from a static folder into a coordinator that fans work out across parallel cloud threads, each running as a full Claude Code session on its own branch and copy of your repo, per Anthropic’s announcement. Threads keep running after you close your laptop, open their own pull requests, and share a memory file that persists across sessions.

Every one of those properties is also a security property. Cloud threads mean your code leaves your machine — the beta requires cloud sessions and effectively requires GitHub, which is why local-only developers are excluded entirely, as ZDNET’s coverage noted. Shared memory means one thread’s compromised context can propagate to every other thread in the project. And a coordinator that auto-spawns threads means an injection that reaches the coordinator doesn’t just corrupt one session — it replicates.

This is the pattern I’d call thread-cost coupling applied to risk instead of billing: each thread is a full session, so each thread is a full session’s worth of exposure. Anthropic markets the multiplier as productivity. It’s also a blast-radius multiplier, and nothing in the launch material frames it that way.

What does Claude Security actually do?

The headline enterprise answer is Claude Security, now in public beta for Claude Enterprise customers, according to Anthropic’s launch post. It scans codebases for vulnerabilities and generates proposed fixes using Opus 4.7, and it was previously known as Claude Code Security — the rename signals Anthropic wants it read as a platform capability, not a CLI feature.

The practical details matter more than the branding:

• Scheduled and targeted scans, plus improved tracking of triaged findings
• Easier integration with audit systems
• No API integration or custom agent build required — it’s accessible directly from the Claude.ai sidebar or at claude.ai/security

That last point is the real differentiator. Most AI-assisted vulnerability scanning requires you to wire an agent into your CI pipeline yourself. Anthropic is betting that a sidebar button beats a build-your-own-agent project for enterprise adoption, and given how few teams ever finish internal tooling projects, they’re probably right.

The catch is the gate. Claude Security is Enterprise-only. If your team runs on Pro or Max — which is exactly the population the Projects beta targets — you get the multi-agent orchestration without the scanning layer. The developers most likely to fan out six parallel threads across a monorepo are the ones without access to the tool that would audit the output.

How exposed are your credentials and plugins?

This is where the evidence gets uncomfortable. Two independent findings in September show the client-side trust model lagging the orchestration ambitions.

First, credential storage. An audit found that Claude Code 2.1.257 stores MCP OAuth credentials as plaintext JSON in ~/.claude/.credentials.json on Linux, protected by Unix mode 0600 rather than encryption, per Magica’s reporting. Mode 0600 stops other users on the box; it does nothing against malware or any process running as you. A separate Mitiga Labs proof of concept showed a malicious npm install hook can rewrite MCP routing and capture refreshed tokens even after rotation — so rotating the token, the standard remediation, doesn’t actually close the hole. To be fair to Anthropic, the scenario requires code already running as the developer plus dynamically authorized MCP servers. It’s not a remote break-in. But “attacker needs to run code as you” describes every compromised npm dependency ever shipped, and Claude Code’s whole job is running code on your behalf. If you’re handling auth flows with Claude Code, we’ve covered the guardrails that actually matter separately.

Second, Plugin4Shell. The mechanism, per the disclosure coverage: an attacker who controls a plugin repository creates a branch named exactly like the pinned 40-hex commit hash and sets it as default. When the agent runs git checkout, the ref resolves instead of the commit object. Review passes, the pin looks honored, and attacker code runs anyway. Background plugin auto-update — enabled by default in both Claude Code and Codex — makes it zero-click on a plugin you already trust.

Patch status varies sharply by vendor:

Tool	Plugin4Shell status	Auto-update default	Practical guidance
Claude Code	Fixed in 2.1.179	Enabled	Upgrade anything below 2.1.179
Codex	Fixed in 0.146.0	Enabled	Upgrade anything below 0.146.0
GitHub Copilot	No fix shipped	—	Treat marketplace plugins as unreviewed
Gemini CLI	Won’t fix (product deprecated)	—	Treat as permanently exposed

Anthropic and OpenAI patched. GitHub hasn’t. Google won’t, because Gemini CLI is deprecated — which is its own lesson about building workflows on vendor CLIs. If your team mixes tools, your exposure is set by the slowest vendor, not the fastest.

What did the recent changelogs actually fix?

The September patch train tells you where the real gaps were. Version 2.1.273 closed three distinct policy holes, per the ClockedCode changelog breakdown: a Bash command the permission checker couldn’t fully analyze could skip the deny/ask prompt under permissions.blockReadsOutsideWorkingDirectories; a subshell could hide a dangerous rm even in bypass mode; and skills synced from claude.ai kept working after an organization turned Skills off — they now move to recoverable trash instead.

The one that should worry platform teams most: allowManagedMcpServersOnly, deniedMcpServers, and disableClaudeAiConnectors set via MDM or managed-settings.json were silently ignored whenever server-managed settings were present. Read that again. An admin’s MCP lockdown could simply not apply, with no error, no warning, nothing. Silent policy failure is the worst failure mode in enterprise tooling because your compliance posture says one thing while the binary does another.

The same release fixed a memory directory being loaded into the prompt, recalled, indexed, and used for extraction even under blockReadsOutsideWorkingDirectories. Given how much rides on what lands in Claude’s memory layer — we’ve written about how the memory file system actually works — a permissions bypass there means sensitive paths could leak into context you assumed was walled off.

Then 2.1.277 added subagent output spoofing protection, which matters directly for the Projects model: when a coordinator consumes reports from parallel threads, spoofed subagent output is how one compromised thread poisons the coordinator’s decisions. That release also added CLAUDE_GATEWAY_PROXY_IS_EGRESS_BOUNDARY=1 and a headers: map for gateway upstream requests, letting teams delegate DNS resolution to a proxy and pin auth headers, per the September 19 briefing. For shops where a forward proxy is the only path out, that consolidates access control at the proxy layer — a real architectural control, not a checkbox.

What controls do Enterprise admins actually get?

The Enterprise story is stronger than the client story, and the gap between the two is the strategic tell. Per Anthropic’s release notes, Enterprise plans can enable skill and plugin security scanning (beta) to automatically check third-party skills and plugins for malicious content when uploaded or edited — a direct organizational-level answer to the Plugin4Shell class of problem, since it moves vetting from “trust the pin” to “scan the artifact.”

HIPAA configuration is now self-serve for both Claude Enterprise and the Claude Platform API, with an eligible admin able to review the BAA and enable the configuration in one flow. And on the data side, memory uses individual, categorized entries, with topics like health or beliefs kept out unless the user explicitly turns on sensitive-topic memory.

The pattern across all three: Anthropic is building the governance layer where the money is. Enterprise gets scanning, audit integration, and self-serve compliance. Pro and Max get the orchestration beta and a changelog. That’s a rational business decision, but you should see it clearly — the security posture of the tool you have is not the security posture of the tool in the keynote.

Should you trust Projects with your codebase?

Here’s my honest read. The architecture is sound — mapping multi-agent conflicts onto ordinary merge conflicts instead of inventing a new primitive was the right call. But the September evidence shows a client whose permission enforcement, credential storage, and plugin trust model are all being patched in real time, while the feature set sprints ahead into autonomous multi-thread execution.

A practical decision framework:

1. If you’re on Enterprise: enable skill and plugin scanning, verify your MDM-managed settings actually apply (test them — don’t trust the silent-failure class is fully closed), and pilot Claude Security on a non-critical repo first.
2. If you’re on Pro or Max in the Projects beta: cap thread counts deliberately, keep MCP server authorization static rather than dynamic, and treat every plugin as unreviewed until you’ve confirmed your version is past 2.1.179.
3. Regardless of tier: run the controls from our AI coding security checklist before you let any coordinator open PRs autonomously — review burden doesn’t shrink because an agent split the work into six threads.

The open question I’d want answered before betting a regulated codebase on this: will Anthropic publish its client-side security model — how credentials are stored, how policy precedence resolves, how coordinator output is validated — with the same rigor it publishes model cards? Until that exists, you’re auditing changelogs to discover your own threat model, and that’s backwards.