Claude Code Projects: Parallel Threads and Shared Memory

Claude Code Projects stopped being a folder this week. Anthropic announced the redesign on September 17, 2026, rebuilding Projects around a coordinator and parallel agent threads for work that outlives a single reply. The old model was a folder of files and notes you re-briefed every session; the new one keeps the context standing and hands Claude the job of dividing the labor.

From folders to one long-running conversation

Projects used to be a container: a folder with files and instructions that made each new session smarter without repeating yourself. The relaunch turns that container into a conversation. In Anthropic’s words, “Projects have threads that do the work and a coordinator that directs them,” a split the announcement sums up as a shift “from folder to conversation.”

The feature is built for long-horizon, multi-part work rather than questions that fit inside one reply. You state a goal and attach repositories or files. The coordinator, a chat that stays open for the life of the project, suggests work for you to approve or redirect. Threads spin up as separate Claude Code cloud sessions, each on its own branch with its own copy of the repo.

Where you use it matters. Claude Code Projects runs at claude.ai/code, in the desktop app’s Code tab, and in the Claude iOS and Android apps. It does not run in the terminal CLI, and it is absent from Amazon Bedrock, Google’s Agent Platform, and Microsoft Foundry.

Rollout began with Pro and Max subscribers who already used cloud sessions and had no existing web or desktop projects, widens over the following week, and reaches Team and Enterprise plans after that. You can start one at claude.com/projects, and claude.com/form/projects is the waitlist for accounts outside the first wave. Existing Pro and Max projects keep working during the rollout, and Anthropic says they will be upgraded as the redesign reaches chat and Cowork.

How the Claude Code Projects coordinator directs threads

Anthropic’s guidance is to brief the coordinator the way you would brief a chief of staff: here is the goal, here is the repo, keep me posted. It breaks the goal into pieces, routes each piece to a new or existing thread, and consolidates the results. You watch from the main project chat or drop into an individual thread, and the cadence is adjustable, from how often Claude checks in to how many threads it opens and how detailed the updates are. It also learns how you like to work and communicate as the project runs.

Each thread is a complete Claude Code session running in the cloud, not a lightweight subtask, and it can split its own work further using subagents, loops, and workflows. If two threads touch the same lines, the collision surfaces as a merge conflict on the pull request, the same way it would between two human branches. For the delegation primitive inside each thread, our Claude Code subagents guide is the grounding.

The announcement’s examples show the intended scale. One project attacked p75 checkout latency by profiling endpoints, testing optimizations, and opening pull requests in parallel. Another retired a deprecated v1 endpoint across API, web, and mobile repositories by giving each repo its own thread. In both cases the human set direction and reviewed output; the coordinator handled scheduling and division.

Setting up your first project

Creating a Claude Code Projects workspace is a sidebar trip: Projects, then New project. Only the name is required. The goal and context fields are optional but worth filling, since repositories, files, and Google Drive documents all count as context and the coordinator uses them to propose work.

The hard prerequisite is GitHub. Code must live on github.com, your connected account needs push access, and the Claude GitHub App must be installed for each repository or organization you add. Tokens minted by the CLI’s /web-setup flow are not sufficient for project threads, and SAML single sign-on organizations may need re-authorization before the app can see repositories. If a thread cannot access your repo, the installations page is the first place to look.

Threads inherit the project’s standing context: its repositories and files, its instructions and memory, each repo’s CLAUDE.md, its skills, and its plugins, plus claude.ai connectors and the project’s cloud environment. They inherit nothing from a local Claude Code install. Files you upload appear under /mnt/project-files inside threads, and an existing cloud session can be promoted with Continue as a project or Move to project.

Shared memory, instructions, and the library

Memory is what makes Claude Code Projects threads feel like one team instead of five strangers. Every thread contributes to and reads from the same project memory, which the Claude Code docs describe as auto-written files indexed by MEMORY.md and managed under Project settings. When one thread learns the release moved to Friday, or why an export was dropped, the next thread starts with that knowledge already in place.

Project instructions are the deterministic half of that context: up to 16,000 characters, delivered to the coordinator and every new thread verbatim. Repo-level rules stay in each repo’s CLAUDE.md. The Library tab collects what the project produces and what you feed it, files you added and artifacts Claude created, while Pull requests and Routines get their own tabs beside it.

Pull requests and the thread board

Threads work on branches cut from the repo’s default branch and open pull requests when asked or when they have a concrete fix. A thread can also keep watching an open PR with auto-fix enabled, and each thread card carries its own actions: Resolve conflicts, Fix CI, Address comments, Review PR, Create PR, and Merge it.

The Overview pane groups Claude Code Projects threads by state: Ready for review, Waiting on you, Working, Landing, Idle, and Resolved. Idle threads auto-resolve after a week and can be reopened. Desktop notifications fire when a thread needs your answer, and the Overview button shows a dot so waiting work is hard to miss.

One behavioral detail trips people early. Approval prompts must be answered inside the thread itself; telling the coordinator to approve something does not reach the thread. Threads operate in auto mode wherever the model allows it, so those prompts are rare, but when one appears it is yours to answer.

Steering the coordinator without micromanaging

Control in Claude Code Projects is conversational. You tell the coordinator things like “Run at most two threads at a time” or “Propose threads and wait for my go-ahead before starting them,” two of the docs’ own suggested phrasings, and it remembers them. The docs are explicit that these are saved preferences rather than enforced caps, so phrase them as policy, then verify the behavior holds.

Other standing orders worth adopting from the docs: keep follow-up questions in the thread that already knows the area, ask for terser updates, send small chores to a cheaper model, hold pull requests until you have approved the plan, and let the coordinator answer quick questions in chat rather than spawning a thread.

Model selection is split by role. New projects default to Opus for both the coordinator and threads, with high effort on threads and low effort on the coordinator, and both dials are adjustable per role in Project settings. Because settings changes apply only to threads started after the change, a running fleet stays stable, but a settings tweak needs new threads before it takes effect anywhere.

Claude Code Projects versus orchestrating agents yourself

None of the underlying ideas are new to anyone who already parallelizes Claude Code. Subagents let one session delegate inside a single conversation, and git worktrees let you run several sessions on one repo without the branches colliding. Our Claude Code worktrees guide covers that do-it-yourself pattern in depth. In both of those setups, you are the coordinator: you decide what to parallelize, you launch each session, and you reconcile the results.

Claude Code Projects moves that coordination layer into the product. The coordinator proposes the split, the threads carry standing memory you do not have to paste in, and the merge conflicts land in pull requests where your normal review process already lives. The trade is control and locality: threads run in Anthropic’s cloud today, configuration lives in Project settings rather than dotfiles, and the daily thread cap plus shared usage limits are the real budget boundary. The 200-thread daily cap is generous for a solo developer; the binding constraint is your plan’s shared limit, which is why the model and effort dials matter more than thread count.

The reasonable split, for now, is task shape. A two-hour refactor with tight feedback loops still belongs in your terminal where you can watch every diff. A multi-day, multi-repo cleanup with independent pieces is exactly what the coordinator model was built for, and it is the first Claude Code surface where the tool, not you, keeps the plan when you close the laptop.

Deep dive: GitHub App wiring and what loads where

The GitHub App requirement deserves its own explanation, because it is the most common setup blocker. Project threads act on your repositories through the Claude GitHub App, installed per repo or per organization, and the docs note that /web-setup tokens cannot substitute for it. SAML SSO organizations additionally need to re-authorize the app. You can audit every installation from the GitHub settings installations page.

What each thread loads follows the project’s shape. Skills, agents, and commands live in the repositories themselves, committed as .claude/skills/, .claude/agents/, and .claude/commands/ directories, so a skill committed to the repo is available to every future thread without reconfiguration. MCP servers come from claude.ai connectors, and with exactly one repository a thread also loads that repo’s .mcp.json. The coordinator conversation itself carries no connectors, which keeps its job narrowly about direction.

Two smaller rules round out the wiring. CLI tools you need inside threads get installed through the environment setup script, so the environment is reproducible rather than hand-tuned. And the coordinator can only add repositories from GitHub owners the project already uses, which prevents an over-eager session from pulling in an unrelated organization’s code.

Deep dive: the inheritance contract, line by line

A thread starts with a precise bundle of context, and knowing its edges saves debugging later. Inherited: the project’s repositories and files, project instructions and project memory, each repository’s CLAUDE.md, skills, and plugins, claude.ai connectors, and the project’s cloud environment, including anything the environment setup script installed. Not inherited: anything from your local Claude Code install, your local settings, your local MCP servers, your session history.

The one repository versus several repositories distinction matters more than it sounds. With exactly one repository, threads also apply that repo’s permission rules, hooks, and env settings from .claude/settings.json, which means your guardrails travel with the code. Add a second repository and those stop applying entirely; CLAUDE.md, skills, and plugins still load from every repo, but the enforcement layer falls away. Teams relying on hooks to block dangerous commands should keep that asymmetry in mind before multi-repo projects.

Uploaded files appear under /mnt/project-files in every thread, and settings changes of any kind affect only threads started after the change. Running threads keep the configuration they started with; only threads launched later see the new settings.

Deep dive: what a Claude Code Projects thread costs

The announcement is candid that Projects can burn through usage limits faster, and the reason is structural: every thread is a full Claude Code session, so a project running five threads is five sessions drawing from the same plan limits you use everywhere else. The Usage pane in Project settings breaks tokens down by thread and model, which is the honest way to see where the budget goes, and the announcement’s own advice is to check project-specific usage and dial model and effort down where a thread does not need them.

Concrete numbers are few but firm. The enforced ceiling is 200 newly created threads per day, counted across every project you own. Threads that hit plan limits retry automatically and resume when limits reset, with one exception: threads started by routines error out instead of retrying. Threads watching pull requests consume usage when CI fails or review comments arrive, so a noisy PR is also a metered event. Idle and archived projects consume nothing.

If you need more headroom, usage credits are an opt-in mechanism for exceeding plan limits, and the “Additional usage credits are required” error is the signal that you have hit the wall. Internally, a thread that reports it reached the turn limit was stopped by the CLAUDE_CODE_MAX_TURNS setting governing its session.

Deep dive: failure modes and recovery

The failure modes worth knowing before they happen are mostly sandbox-related. Thread sandboxes pause between turns, and if a sandbox cannot resume, uncommitted changes inside it can be lost. The practical habit is letting threads commit early and often, so a dead sandbox costs a turn of work rather than a day of it.

The error catalog maps cleanly to fixes. “Unable to access your repository” points at the GitHub App installation. “Setup script failed” points at the environment script. “Claude ran out of context on this turn” means the thread’s window filled, and “Reached the turn limit” is the CLAUDE_CODE_MAX_TURNS ceiling again. For a thread that has gone quiet with “Claude hasn’t responded,” the Restart Claude action in Project settings is the documented recovery, and Pause, Archive, and Delete round out the lifecycle controls sitting next to it.

Structural limits are worth planning around too. A project has exactly one user, with no sharing, and threads cannot move between projects or out to a standalone session. Threads run in the cloud today; the announcement says execution on local machines and behind your network is coming soon, which will matter for private code that cannot leave the perimeter. When local execution ships, the calculus changes for every repository that can never be uploaded.