# Claude Code Projects: the consumer-plan trap for EU teams

Anthropic relaunched Claude Code Projects on 17 September as a coordinator running parallel cloud threads that open and auto-fix pull requests, but the beta runs only on consumer Pro and Max plans, with no organisation-level controls, no Foundry route and github.com only. For Swedish and EU teams on Azure, that means company code processed under an employee's personal privacy settings unless you set a policy and use the GitHub App install as your control point.

- Published: 2026-09-21 · Category: Security & Compliance · Tags: Claude Code, Anthropic, AI Agents, Governance, GDPR, NIS2, Microsoft Foundry, GitHub, Azure Pipelines, Developer Tools
- Author: Technspire AB, Stockholm (https://technspire.com)
- Canonical: https://technspire.com/en/blog/claude-code-projects-consumer-plan-trap-eu-teams

On 17 September 2026 Anthropic relaunched Projects in Claude Code as a coordinator that splits a goal into parallel worker threads, each one a full Claude Code cloud session on its own branch, opening its own pull request. The beta is available on Pro and Max plans only. Anthropic's documentation states that Projects "aren't available on Team or Enterprise plans yet" and that "there are no organization-level controls for projects during the beta."

Read those two sentences together and the governance problem is obvious. The developers most likely to try parallel agents this month are the ones who already pay for a personal Max subscription. The repositories they will point it at belong to their employer. For a Swedish or EU organisation that has negotiated commercial terms for AI tooling, or that runs Claude through Microsoft Foundry precisely to keep it inside an Azure contract, that combination deserves a decision before it becomes a habit.

## What a project actually does

A project is one long-running conversation where Claude acts as coordinator. You paste in a bug report, a spec or a list of tasks. The coordinator decides whether to answer in place or start a thread, and it tracks every thread it started. Threads are the workers: separate cloud sessions with their own context windows, each on a new branch cut from the repository's default branch.

Four defaults matter more than the marketing suggests:

- **Model and effort.** A new project runs Opus everywhere, with high effort on threads and low effort on the coordinator. Anthropic's own setup advice is to check this first, because it "draws on your plan fastest".
- **Permission mode.** Threads run in auto mode when the model supports it, so most tool calls execute without asking. Approval prompts that do appear live inside the individual thread, and telling the coordinator to go ahead does not reach them.
- **Pull request watching.** Once a thread opens a pull request, it watches it with auto-fix turned on, whether or not you use auto-fix elsewhere. It pushes fixes when CI fails and responds to review comments.
- **Shared memory.** Every thread reads a `MEMORY.md` index at start. Claude writes those memory files itself as the project runs, and you can edit or delete them under Project settings. Project instructions of up to 16,000 characters go to every new thread as a standing brief.

Each thread also loads the `CLAUDE.md`, skills and plugins from every repository in the project. Permission rules and hooks from `.claude/settings.json` apply only when the project has exactly one repository. Add a second repository and those guardrails stop applying to threads, which is the kind of detail that should be in a team's rollout notes rather than discovered in a post-incident review.

## Why the plan restriction is the real story

Anthropic's own data usage documentation groups Free, Pro and Max as consumer plans, and the difference in terms is concrete.

| Topic | Free, Pro, Max (consumer) | Team, Enterprise, API (commercial) |
| --- | --- | --- |
| Model training | Used for training when the user's model-improvement setting is on | Not used for training unless the customer opts in, for example via the Development Partner Program |
| Retention | 5 years with the setting on, 30 days with it off | 30 days standard; zero data retention available to qualified Enterprise accounts |
| Who controls the setting | The individual user, at any time | The organisation, under its agreement |
| Governing terms | Consumer Terms | Commercial Terms of Service |
| Session sharing | Private or Public (visible to any logged-in claude.ai user) | Private or Team, with repository access verification on by default |

Anthropic's cloud execution documentation says code and session data in cloud sessions "are subject to the retention and usage policies for your account type". A thread clones the repository into an Anthropic-managed VM, and the prompts, code changes and outputs follow the policy of whoever owns the account. When that account is a personal Max subscription, your source code is governed by a privacy toggle on an employee's profile page.

Projects themselves cannot be shared with another user, so the Public visibility option does not apply to a project's threads. It does apply to ordinary cloud sessions on the same account, and a developer experimenting with Projects will almost certainly be running those too.

## Where it does not fit an Azure estate

Set aside the plan question for a moment. Even on its own technical terms, Projects makes assumptions that many Microsoft-centred teams do not meet.

**GitHub.com only.** Project threads need code on github.com, the Claude GitHub App installed on each repository, and push access from the connected account. GitHub Enterprise Server, GitLab and Bitbucket are named as unsupported for projects. Azure Repos is not mentioned at all. Ordinary cloud sessions can take a non-GitHub repository as an uploaded bundle, but they cannot push results back to it.

**No Foundry route.** The Projects documentation lists the limitation directly: projects are not available through Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry, and threads are cloud sessions "with Anthropic as the model provider". If your organisation chose Claude in Foundry to keep billing, identity and data handling inside an Azure agreement, none of that carries over. We covered what the Foundry hosting options do and do not guarantee when [Claude Fable 5.1 landed in Foundry](/en/blog/claude-fable-5-1-foundry-cache-math-eu-caveats).

**Self-hosting does not rescue it yet.** Anthropic offers self-hosted environments where cloud sessions execute on runners inside your own network. They are in public beta on Team and Enterprise plans only, off by default, and inference still goes to `api.anthropic.com`; it cannot be routed through Foundry or an LLM gateway. Because Projects are not on Team or Enterprise, the two features do not currently meet. Anthropic's launch post says running threads "on your machine alongside your local tools and code and behind your network is coming very soon", without a date.

**Your existing controls can break it, or be bypassed by it.** Organisations with zero data retention enabled cannot use cloud sessions at all. Organisations that enforce an IP allowlist on their Claude organisation will see Anthropic-hosted cloud sessions fail with authentication errors, because the sessions call the API from Anthropic's infrastructure. Both are reasonable outcomes for a governed organisation account. Neither applies to a personal subscription, which is exactly why the personal route is the one that will get used.

## The usage math, without invented numbers

Projects draw on the same plan limits as every other Claude Code session, and Anthropic is candid that they use them faster: "on a Pro plan in particular you should expect to reach your limit sooner on days you run one." There is no separate compute charge for the cloud VM. What consumes the plan is spelled out in the documentation:

```
Project consumption per usage window
  = coordinator tokens            (reads thread reports, routes work)
  + sum over running threads      (each one a full Claude Code session)
  + wake-ups on watched PRs       (CI failure or review comment revives an idle thread)
  + cold re-reads                 (follow-up to a thread idle past the cache
                                   lifetime re-reads its whole conversation)

Hard limits documented by Anthropic
  new threads per day, across all projects    200
  concurrent threads                          no fixed number
  "run at most two threads" instruction       preference, not a cap
```

Two behaviours matter for anyone thinking about cost on behalf of a team. First, a thread that hits the five-hour or weekly limit does not stop. It retries and continues automatically when the limit resets, so work left running overnight starts consuming the next window without a message from anyone. Second, a concurrency limit you give Claude in conversation is saved to memory as a preference and is not enforced. If you want a real cap, the controls are Pause on the project, Stop on the thread, or a smaller thread model in Project settings.

On an individual subscription, none of that reaches your finance team, which sounds convenient until you realise it also means nobody on the company side can see or cap how much of your codebase is being processed. The cost lens and the governance lens point at the same gap. For the token-reduction side of running Claude Code at scale, the patterns in [Spotify's 90 per cent token cut](/en/blog/spotify-cut-claude-code-tokens-90-copy-the-pattern) apply to threads just as they do to single sessions.

## The auto-fix side effect nobody budgets for

When auto-fix replies to review comments on GitHub, Anthropic's documentation states that "these replies are posted using your GitHub account". Each reply is labelled as coming from Claude Code, but it arrives as a comment from a real user. The documentation carries an explicit warning: if a repository runs comment-triggered automation such as Atlantis, Terraform Cloud or GitHub Actions on `issue_comment` events, Claude replying on your behalf can trigger those workflows.

Azure teams should add their own item to that list. Azure Pipelines building GitHub repositories supports comment triggers on pull requests, where a comment from an authorised contributor starts a pipeline run. An agent posting as a contributor is, from the pipeline's point of view, that contributor. Review which repositories allow comment-triggered runs and what those runs can reach before any thread is allowed to watch a pull request there. Anthropic's own advice is to consider disabling auto-fix "for repositories where a PR comment can deploy infrastructure or run privileged operations." In a project, auto-fix is on for every pull request a thread opens unless you tell it to stop.

This sits on top of the isolation questions we raised in [A classifier is not a sandbox](/en/blog/coding-agent-sandboxing-auto-mode-break) and the malicious-repository scenario in [GitSpawn](/en/blog/gitspawn-malicious-repo-can-hijack-your-coding-agent). Parallel threads in auto mode add more sessions to that same exposure, each with push access.

## The Swedish and EU angle

Three points make this sharper for organisations here than for a typical US software shop.

**Repositories contain personal data more often than teams admit.** Test fixtures with real customer rows, log excerpts pasted into issues, seed scripts copied from production. Under GDPR, sending that material to a processor requires an agreement the organisation controls. A personal consumer subscription is an agreement between Anthropic and the employee. The data processing commitments your procurement team negotiated sit under commercial terms, and they do not follow code that a developer sends through their own account.

**NIS2 and supply-chain obligations cover the tooling path.** Entities in scope of NIS2, which covers far more sectors than the directive it replaced, are expected to manage risk in their ICT supply chain. An autonomous agent with push access to production repositories, operating under an individual's credentials and outside any organisational control plane, is a supply-chain dependency whether or not anyone approved it. The GitHub App installation is the one artefact that shows up on the organisation's side.

**Public-sector buyers who chose the Foundry route did so for a reason.** An agency or municipality that procured Claude through its Azure agreement did so to keep contract, identity and data handling in one place. Projects bypasses that path completely. For these buyers the realistic decision is to wait for the Team and Enterprise rollout and the local-execution option, then evaluate again, while blocking the consumer route in the meantime.

## What to do this week

**The control point is GitHub, not Anthropic.** During the beta there are no organisation-level project controls. Every project thread needs the Claude GitHub App installed on its repositories, and on an organisation-owned repository only an organisation owner can complete that install.

- **1. Audit installed GitHub Apps.** In each GitHub organisation, check whether the Claude GitHub App is already installed and which repositories it can reach. Pending install requests from members are the early signal that someone wants to use Projects.
- **2. Decide the policy, then write it down.** Either personal subscriptions may not touch company repositories, or they may under stated conditions. Both are defensible. Silence is not, because the default outcome is individual employees deciding.
- **3. Map comment-triggered automation.** List every repository where a pull request comment can start a GitHub Actions workflow, an Azure Pipelines run or an infrastructure apply. Those repositories should not receive auto-fix from any agent until the trigger requires a maintainer role the agent's account does not have.
- **4. Put the useful work in the repository now.** Threads load `CLAUDE.md`, skills under `.claude/skills/` and agents under `.claude/agents/` from every repository in a project. The same files serve local Claude Code today, so the investment is not wasted if you wait.
- **5. Give developers a sanctioned alternative.** Local Claude Code can run against Claude models deployed in your own Foundry resource by setting `CLAUDE_CODE_USE_FOUNDRY=1` and `ANTHROPIC_FOUNDRY_RESOURCE`, with Entra ID through the default Azure credential chain. Parallel work locally is possible with worktrees or agent teams. It lacks the coordinator and the phone-friendly overview, but it stays inside your contract.
- **6. If you are on Team or Enterprise, prepare the cloud path.** Check whether cloud sessions are enabled, whether your IP allowlist would block them, and whether self-hosted environments are worth piloting. When Projects arrives on those plans, you will want the environment, network rules and repository permissions already decided.

```
# Sanctioned local setup: Claude Code on your own Foundry deployment
export CLAUDE_CODE_USE_FOUNDRY=1
export ANTHROPIC_FOUNDRY_RESOURCE=<your-foundry-resource>
export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-8'
export ANTHROPIC_DEFAULT_SONNET_MODEL='claude-sonnet-5'
az login          # Entra ID via the default Azure credential chain
claude            # /status should report Microsoft Foundry as the provider
```

Pin model versions on every Foundry deployment before rolling this out to a team; Anthropic warns that unpinned aliases resolve to a built-in default that can lag the newest release and fail if that model is not deployed in your account.

## When to look again

Two announced changes would move Projects from "block" to "evaluate" for most regulated teams. The first is the Team and Enterprise rollout, which Anthropic says follows the Pro and Max expansion, bringing projects under commercial terms and, presumably, some organisational controls. The second is local or in-network thread execution. Even then, inference goes to Anthropic's API rather than to a Foundry deployment, so organisations whose requirement is specifically Azure-hosted inference should expect the gap to remain until Anthropic says otherwise.

The coordinator model itself is a genuine step for long-running engineering work: a single brief, shared memory and parallel branches that land as reviewable pull requests. Adopt it when it runs under an account your organisation owns. Until then, the setting that decides what happens to your source code belongs to whoever pays for the subscription.

## Sources

- [Anthropic: Projects redesigned, from folder to conversation (17 September 2026)](https://claude.com/blog/projects-redesigned)
- [Claude Code docs: Let Claude coordinate ongoing work with Projects](https://code.claude.com/docs/en/claude-projects)
- [Claude Code docs: Use Claude Code in the cloud (auto-fix, security, limitations)](https://code.claude.com/docs/en/claude-code-on-the-web)
- [Claude Code docs: Data usage, training and retention by account type](https://code.claude.com/docs/en/data-usage)
- [Claude Code docs: Self-hosted environments](https://code.claude.com/docs/en/self-hosted-environments)
- [Claude Code docs: Claude Code on Microsoft Foundry](https://code.claude.com/docs/en/microsoft-foundry)

---

Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt