Claude Code Projects, Explained

Published September 23, 2026 · by the AQ team

Claude Code Projects is Anthropic's redesigned Projects experience for Claude Code, launched in beta on September 17, 2026. A project is one persistent conversation in which Claude acts as a coordinator: you describe what needs doing, and it scopes the request, starts parallel threads (each a full Claude Code cloud session with its own branch and its own copy of the repository), reviews what comes back, and assembles the result. Threads share the project's memory, instructions, and a library of files, keep running after you close your laptop, and can be checked and steered from a phone. As of September 2026 it is in beta for select Pro and Max subscribers who use cloud sessions, threads run only in the cloud (local execution is "coming very soon"), and, per Anthropic's own documentation, a project belongs to one user and cannot be shared. This guide explains how it works, what it deliberately is not, and where a team workspace that runs any agent CLI fits alongside it.

What a project actually is

Anthropic's docs describe three parts. The project conversation is one long-running session where Claude coordinates: it takes whatever you paste in (a bug report, a stack trace, a batch of tasks), decides what becomes a thread, routes follow-ups to the thread already working in that area, and answers quick questions in place. It sees what threads report, not every step they take. Threads are the workers: each is a separate cloud session with its own context window that does one piece of work on its own branch, opens a pull request when the work calls for one, and reports back when it finishes. The Overview pane tracks them all, grouped by state: ready for review, waiting on you, working, landing, idle, and resolved, plus tabs for its file library, pull requests, and scheduled routines.

The pitch, in Anthropic's framing: running several sessions without a project means being the scheduler yourself. A project moves that work onto Claude. You send work to one place, set context once, and come back to finished threads and open pull requests.

What every thread starts with

The standing context is the substantive change over the old Projects (which was a folder of files plus a chat). Per the docs, every new thread starts with:

• Project memory. Notes Claude writes itself about requirements, decisions, and pitfalls, stored as files with a MEMORY.md index every thread reads at start. You ask Claude to remember or forget things, and can read, edit, and delete the files in project settings, so the memory is inspectable, not a black box.
• Project instructions. A brief of up to 16,000 characters sent to each new thread: which branch to target, how a thread should check its work, what needs your go-ahead.
• Repositories and environment. Each thread clones every project repository into its own cloud sandbox and loads their CLAUDE.md files and skills. A cloud environment sets network access, environment variables, credentials, and tools.

When threads change code, each works on a new branch cut from the default branch, can open a pull request on its own for a concrete change, and then watches that pull request with auto-fix on: pushing fixes when CI fails and addressing review comments. Because every thread has its own branch and repository copy, overlapping work is not silently merged; it surfaces as an ordinary merge conflict for you to resolve.

Usage, limits, and models

There is no separate price. A project draws on the same Pro or Max plan limits as your other Claude Code sessions, and Anthropic is direct that it uses them faster: each thread is a full session and several run at once, so Pro users in particular should expect to hit limits sooner on project days. The enforced cap is 200 new threads per day across your projects; a limit you ask for in conversation ("run at most two threads at a time") is a preference Claude keeps to, not a hard cap. A new project defaults to Opus at high effort for threads; you can pick smaller models and lower effort per thread or for the coordinator. Two quieter costs: the coordinator spends tokens reading thread reports, and an idle thread watching a pull request wakes and spends again when CI fails or a review comment arrives.

What Claude Code Projects is not

Three boundaries matter, all stated in Anthropic's own material as of September 2026.

It is one person's project. The docs say it plainly: "A project belongs to one user. You can't share a project or its threads with another user," thread transcripts lack the share option other cloud sessions have, and there are no organization-level controls during the beta. Teammates cannot open your project, see its threads, or steer one; Anthropic points team use at Claude Tag in Slack instead, where a channel sees the work but nobody is inside the session. That default reinforces how agent-assisted work already tends to go: a July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. A coordinator that multiplies one person's parallel output, visible to that person alone, compounds that pattern.

It is one vendor's agent, in one vendor's cloud. Threads are Claude Code cloud sessions on Anthropic-managed infrastructure, with Anthropic as the model provider. The launch post says threads "run in the cloud today" with execution on your own machine and behind your network "coming very soon," but as of September 2026 a local session cannot be part of a project. Repositories must be on github.com (not GitHub Enterprise Server, GitLab, or Bitbucket) with the Claude GitHub App installed, and Projects is not available through the terminal CLI, Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry. If your stack runs Codex or Cursor alongside Claude, those agents live outside it.

Threads are not your dev environment. A thread's sandbox pauses between turns and, if it cannot be resumed, the thread continues from a fresh clone, so uncommitted changes can be lost; Anthropic recommends committing and pushing work in progress on long tasks. Work that needs a local database, a device emulator, or an API behind your VPN is out of scope today; Anthropic points those cases at local sessions and agent view, which tracks parallel local sessions but has no coordinator.

Where a team workspace that runs any agent CLI fits

Projects answers "how does one person stop being the scheduler between their own agents." It does not try to answer the question teams hit next: how does everyone see, join, and steer the agent work now running all day? If your team runs more than one agent CLI, wants sessions on infrastructure you control, or wants a second engineer able to open a live session rather than read its PR afterward, you need a workspace layer rather than a per-user coordinator. You can assemble one by hand (a VM, tmux, and per-task git worktrees; keeping Claude Code running after closing your laptop covers the persistence half); what remains is the team layer: shared visibility, isolation between parallel tasks, and tracking the PRs agents open.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. The contrast with a project is close to exact. A project is one person's coordinator over one vendor's cloud sessions; an AQ workspace is a place your whole team is inside. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser, so sessions survive a closed laptop and resume from any device. Teammates open the same workspace and watch the same live session, and the owner can delegate typing by approving a control request in one click. Each workspace gets its own isolated git worktree, agents commit and open PRs with per-user GitHub auth, every workspace serves a live dev-server preview with shareable links, and each engineer signs into the CLIs with their own Claude or OpenAI account, which AQ never marks up. The Free plan is a personal sandbox on a private machine AQ creates, with no time limit; the Team plan is $50 per user per month in early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM, rate locked for your first 12 months. AQ vs Claude Code on the web compares the underlying cloud-session layer directly.

Plainly: if you are one engineer on a Max plan shipping solo work through pull requests, Claude Code Projects is a real step forward and you should try it. A team workspace earns its place when the unit of collaboration is the live session itself, across the agent CLIs your team actually uses, on machines you control.