How to Use Claude Code Projects

Claude Code Projects lets you give one conversation a stream of development work, then let that coordinator start and track separate cloud threads for the individual tasks. The payoff is not more chat windows. It is less time spent repeating repository context, dispatching sessions, and hunting for the branch or pull request that needs you.

The redesigned experience began rolling out on September 17, 2026, and access is still selective. This guide shows how to check your account, set up one disposable repository, send two disjoint tasks, review the resulting work, and understand exactly which context follows every thread.

Claude Code Projects is a coordinator, not a folder

A Claude Code project is one persistent conversation with Claude plus the cloud sessions it starts as threads. Think of the conversation as a model-shop foreman. You hand the foreman a brief, and separate work bays handle the jobs. Each bay has its own workspace, context window, and Git branch, while the foreman receives the reports and keeps the queue organized.

That is different from the earlier Projects experience in Claude chat and Cowork. The older version groups conversations and reference files. The new Claude Code Projects beta adds a coordinator that routes work to cloud threads, follows their status, and carries project context into new threads.

Every thread begins with the project's repositories and files, instructions, memory, selected cloud environment, account connectors, and the CLAUDE.md, skills, and plugins in its repositories. Threads do not inherit tools that exist only on your laptop.

The direct software math is favorable if you already pay for an eligible Claude plan. Claude Pro costs $20 monthly, or $17 per month with a $200 annual payment, and Max starts at $100 monthly. Projects adds no separate cloud virtual-machine charge. The catch is usage: every thread is a full Claude Code session, so parallel work consumes the same plan limits faster.

For comparison, the individual coding-agent subscriptions checked for this guide span $10 to $200 per month across GitHub Copilot and Cursor. Projects is not a new seat to add to that stack if Claude is already your coding agent. It changes the coordination line item, not the engineering judgment line item.

First, check whether your account has the beta

Access requires more than seeing a feature named Projects somewhere in Claude.

1. Sign in with a Claude Pro or Max account.
2. Open claude.ai/code or the Code tab in the desktop app.
3. Look for Projects in the left sidebar.
4. If it is missing, the rollout has not reached your account. Join Anthropic's waitlist and use ordinary cloud sessions in the meantime.

The first wave favors Pro and Max accounts that have already used cloud sessions and do not have older Projects in Claude chat or Cowork. Team and Enterprise accounts do not have this redesigned beta yet. Existing older Projects continue to work while Anthropic migrates the experience.

If you still need Claude Code installed, authenticated, and grounded with a repository-level CLAUDE.md, start with the general Claude Code setup guide. Projects sits on top of those repository practices. It does not replace them.

Set up your first project around a disposable repository

Use a small GitHub repository you can safely throw away. The goal of the first run is to inspect routing, context, branches, and usage, not to entrust a production migration to a beta coordinator.

1. Fix GitHub access before creating the project

For code work, the repository must be on github.com. Your connected GitHub account needs push access, and the Claude GitHub App must be installed for that repository. A token created through /web-setup may let an ordinary cloud session clone a repository, but it is not enough for a project thread.

GitHub Enterprise Server, GitLab, and Bitbucket repositories are not supported as project code repositories in this beta. If the repository belongs to an organization, an organization owner may need to approve the GitHub App installation and SSO authorization.

2. Create a narrow project

Open Projects, select New project, and add:

• Name: something unmistakably temporary, such as Parser Project Test.
• Goal: one sentence, such as Improve parser coverage and documentation without changing behavior.
• Context: add only the disposable repository.

Only the name is required. A narrow goal gives the coordinator a useful boundary, and one repository avoids the settings differences that appear in multi-repository projects.

3. Add one standing instruction

Open Project settings > Memory > Project instructions. Give every thread the same definition of done and the same approval boundary. For example:

Start from the default branch. Use one branch per thread. Run the relevant tests before reporting completion. Do not merge, change CI, or add dependencies without asking in the thread. If access is missing, name the missing item and stop.

Project instructions can be up to 16,000 characters, but the first test should stay short. Repository-specific build commands still belong in that repository's CLAUDE.md. Requirements, decisions, and pitfalls that emerge across the project belong in project memory.

4. Check the cloud environment

Open Project settings > Environment. Every new thread uses the environment selected here. It controls network access, environment variables, API credentials, and tools installed by a setup script.

The default Anthropic-hosted environment reaches an allowlist of common services and includes preinstalled tools. It does not automatically gain your local database, VPN, device emulator, shell configuration, or laptop-only credentials. Configure the environment before assigning work that depends on any of those things.

5. Send two tasks that cannot collide

Put both tasks in one message so you can see the coordinator split unrelated work. Keep them in different files. For example:

Start now without asking for confirmation. Create one thread to add unit tests for malformed parser input. Create a second thread to correct outdated examples in the API guide. Do not change production parser behavior, and do not merge either branch.

Anthropic says several unrelated tasks in one message become separate threads. Each code thread starts a branch from the repository's default branch unless you tell it otherwise. Disjoint files matter because separate branches can still conflict when two threads change the same code.

6. Review the threads, not just the coordinator's summary

Open each thread card and record:

Overview groups work into Ready for review, Waiting on you, Working, Landing, Idle, and Resolved. Its other tabs collect project files, pull requests, and routines. The coordinator sees thread reports, but it does not see every step, so the thread transcript remains the place to audit the work.

7. Test whether later work sees the saved context

After both threads finish, tell the coordinator to remember one harmless rule, such as Documentation changes must preserve every runnable example. Then start a fresh, small documentation thread and ask it to state the project's branch rule and documentation rule before editing.

This checks two different context paths. Project instructions should reach every new thread as a fixed brief. Project memory should carry the saved decision through MEMORY.md. A repository's CLAUDE.md remains a third, separate layer for rules that belong to the codebase itself.

What follows a thread, and what stays behind

The fastest way to misread Projects is to assume a cloud thread is a remote copy of your laptop. It is not. It is a fresh cloud session assembled from project, repository, account, and environment context.

There is one multi-repository trap worth knowing. All repository CLAUDE.md files, skills, and plugins load in a project with several repositories, but repository permission rules, hooks, and env settings do not. Put cross-repository rules in project instructions and environment variables in the cloud environment.

Parallel threads are not unlimited threads

Anthropic documents no fixed number of threads that may run concurrently. You can ask the coordinator to run two at a time, but that is a preference, not an enforced quota. The separate hard ceiling is 200 new threads per day across your projects.

Running threads use the plan. The coordinator uses the plan while reading reports and deciding what happens next. A thread watching a pull request wakes up and uses the plan again when CI fails or a review comment arrives. An idle project with no running threads, watched pull requests, or new messages uses nothing while it sits.

New projects default to Opus with high effort for threads and low effort for the coordinator. Before a large batch, open Project settings > General and choose the least expensive model and effort level that can do each job. Then ask for a small concurrency count. The useful number is not how many threads Projects can start. It is how many results you can review before the queue becomes noise.

The seven use cases that benefit most

1. A platform lead coordinating a multi-repository migration

Connect the server, web, and mobile repositories, then give the project one retirement goal for a deprecated endpoint. Separate threads can update each caller on separate branches while the coordinator tracks ordering and blockers. The payoff is a single review queue instead of three manually synchronized agent sessions. This is the strongest fit because the goal outlives one session and the work divides cleanly by repository.

2. A maintainer feeding one service's bug queue

A maintainer can paste fresh bug reports and stack traces into the same project as they arrive. The coordinator can route a regression to the thread already investigating that area or start a new one with the project's saved pitfalls. The payoff is less briefing repetition and a durable record of which bug is waiting for access, review, or a decision.

3. A release owner running independent readiness checks

Give separate threads the test suite, documentation links, dependency audit, and release-note draft. Keep each task read-only until the findings are reviewed. The coordinator can surface what passed and what needs an answer without blending the evidence into one huge transcript. The payoff is shorter time from checklist to a decision, while the release owner keeps the final call.

4. A refactor lead splitting a large change by boundary

For a migration larger than one context window, assign independent modules or packages to separate threads and put the invariant in project instructions. Each thread validates its own branch and reports back. The payoff is parallel progress with one standing definition of done. The catch is architectural overlap: two branches touching the same shared abstraction can still produce ordinary merge conflicts.

5. An agency engineer maintaining a client application

Create one private project for one client's repository, instructions, and environment. Feed it small fixes, review requests, and documentation work across the engagement. The payoff is continuity without mixing client context. Projects belong to one user and cannot be shared during the beta, so this is a personal delivery cockpit, not a client collaboration portal.

6. A support engineering lead analyzing recurring integration failures

Projects do not require a repository. Upload a support-ticket export and integration documentation, then send threads to classify failures, verify examples, and draft a remediation brief. Their output files land in Library. The payoff is one reusable body of project context and separate evidence trails for analysis and writing.

7. A solo founder clearing a mixed backlog

Send a small batch containing one test task, one documentation task, and one repository audit. Tell the coordinator to run only two threads and propose any destructive change first. The payoff is attention: the founder reviews completed branches instead of babysitting each session. It is a poor fit when every task needs the same file or a service reachable only from the founder's laptop.

Three companion products worth building

The beta does not expose a documented Projects API, so the sensible near-term products sit beside the workflow. They prepare context, inspect GitHub state, or help a human review the output.

1. Project Readiness Auditor, the strongest opportunity

Build a read-only GitHub app that checks whether a repository is ready for cloud coding agents. It would inspect repository instructions, test commands, branch protections, GitHub App coverage, required secrets, and network dependencies, then produce a project-instructions draft and a cloud-environment checklist.

Demand is already visible around the job: “ai powered coding agent” receives 8,100 US searches a month with commercial intent. Official individual coding-agent plans checked for this guide range from $10 to $200 per month, yet a paid seat does not make a repository safe for parallel cloud work.

The smallest sellable version scans one GitHub repository, asks six environment questions, and exports a paste-ready brief. The catch is platform risk. Anthropic or GitHub could absorb setup checks quickly, so the product needs cross-agent support and a useful audit history rather than one Claude-specific template.

2. AI delivery lifecycle board

Build a GitHub-backed board that groups branches, pull requests, CI status, review comments, and human approvals by delivery goal. It would serve a technical lead who uses several coding agents and needs one neutral review surface.

“AI software development life cycle” receives 720 US searches a month, has keyword difficulty 4, and carries an $18.13 CPC. The smallest version reads GitHub events and turns them into four states: working, blocked, ready, and landed. It never needs private access to a Claude project transcript.

The catch is differentiation. GitHub and agent vendors already show much of this state. The product wins only if it connects work across vendors, preserves approval evidence, and explains why a change is blocked rather than drawing a prettier queue.

3. Automated review policy router

Build a GitHub app that applies repository-specific review policy to agent-created pull requests. It could demand a test artifact for parser changes, route billing changes to a named reviewer, and stop auto-fix comments from triggering privileged automation.

“Automated code review” receives 210 US searches a month and carries a $63.33 CPC, a strong signal that the smaller audience has expensive intent. The MVP needs a policy file, a pull-request check, and a compact explanation of which evidence is missing.

The catch is overlap. Claude threads already watch pull requests and react to CI failures and review comments. A new product must govern risk across agents and repositories, not imitate another reviewer bot.

What Claude Code Projects does not solve

Projects is best when work can be divided and the required context can live in GitHub, uploaded files, connectors, or a cloud environment. It is the wrong tool for a one-off fix that fits one session, work tied to a local device or VPN, or a team that needs several people to steer the same project.

It also does not remove ordinary delivery risk:

• Separate threads can create merge conflicts when their branches overlap.
• A concurrency request is a coordinator instruction, not a hard budget control.
• Parallel threads can exhaust Pro limits quickly.
• A paused sandbox may resume from a fresh clone, so uncommitted work can be lost.
• The beta is personal, with no project sharing or organization-level controls.
• A thread cannot be moved to another project later.

The honest take is simple: use Projects to coordinate separable work, not to outsource architecture or approval. Start with two tasks, inspect both transcripts, and raise concurrency only after the branches and usage look predictable.

Frequently asked questions

Does Claude Code have access to projects?

Selected Claude Pro and Max accounts can use the redesigned Projects beta at claude.ai/code, in the desktop Code tab, and in Claude's mobile apps. If Projects is absent from the Code sidebar, the rollout has not reached that account. The terminal command named claude project manages unrelated local directory state.

How do I use projects in Claude Code?

Create a project in Claude Code, add a goal and the minimum repositories or files it needs, write a short standing instruction, select the cloud environment, then send one or more tasks to the coordinator conversation. Review each thread in Overview and inspect its branch, transcript, validation, and usage before merging anything.

Can Claude Code work on an existing project?

Yes. You can create a project around an existing github.com repository or choose Continue as a project from an existing cloud session. Code repositories need push access through your connected GitHub account and the Claude GitHub App installed for them.

What are the key differences between Claude projects and Claude code?

Claude Code is the coding agent that runs in a local or cloud session. A redesigned Claude Code project is the coordination layer: one conversation starts and tracks several Claude Code cloud sessions, gives them shared project context, and collects their status. Older Projects in Claude chat and Cowork are still the file-and-conversation workspace model until migration reaches them.

If you want a project-ready agent workflow built around your repositories, approvals, and cloud environment, see AI production systems.