Claude Code Launches Redesigned Projects: A Central Conversation as Coordinator, Spawning Parallel Cloud Threads That Persist When Laptops Close

In legacy Claude Projects (projects within claude.ai chat and Cowork), a project was merely a folder grouping conversations and reference files together, lacking both threads and a coordinator. If you wanted to run multiple Claude Code sessions at once, all the coordination fell on you: deciding what each session should do, repeating the exact same background context at the start of every session, and manually checking back to see which had finished and which was waiting on your input. Whenever you faced a multi-day task spanning multiple code repositories, you effectively acted as the dispatcher.

Anthropic has rolled out a newly redesigned Projects feature across the web version of Claude Code (claude.ai/code) and the desktop client, currently in public beta for Pro and Max subscribers. The core shift of this revamp is moving from a "static folder" to a "shift supervisor": the entire project converges into an ongoing, central conversation where you specify goals, and Claude acts as the coordinator, automatically decomposing requirements into multiple parallel threads.

Threads here are not simple background shell commands; each thread is fundamentally an independent cloud session of Claude Code. Each possesses its own dedicated context window, writes code, runs tests, and opens PRs when needed in an isolated cloud sandbox on its own git branch—and continues running even after you close your laptop lid and go offline.

Key capabilities of Projects:

• Dispatch from a single conversation: Drop tasks, bugs, and clarifications into the same project conversation; Claude decides whether to answer in place, spin off a new thread, or route the request to a thread already handling that area.
• Parallel threads that persist when your computer is closed: Each thread is an independent cloud session of Claude Code with its own context window, code copy, and branch.
• Notifies you only when needed: The Overview panel groups threads by status, queuing blocked items awaiting your decision under Waiting on you, while the desktop app also pushes notifications.
• Shared context and memory: Every new thread kicks off with the same project instructions, repositories, and project memory; decisions you ask Claude to remember are known to subsequent threads.
• Autonomous PR follow-up: Once a thread opens a PR, it keeps monitoring it, automatically pushing fixes if CI fails or review comments arrive, and only alerting you once checks pass.
• Scheduled runs: You can instruct Claude to turn portions of your work into routines that run automatically inside the project on a schedule.
• Beyond writing code: Works even without code repositories—upload documents and let threads conduct research and write reports, delivering deliverables directly to the Library.

Execution Mechanics: How Does a Single Compound Message Turn into Multiple Parallel Threads?

The official launch video demonstrates a typical morning: inside a service project named checkout-service, a user enters a single compound instruction containing three requests—"p99 on /checkout doubled after deploy #4812, find it and fix it. Also draft Friday's release notes, and bump stripe-node to v15."

Within the project, Claude in the main conversation serves as the coordinator, observing results reported back by threads rather than their granular execution steps. Claude autonomously determines where messages go: quick and simple questions are typically answered right in the conversation; new work spins off a new thread or gets delegated to an existing thread already working in that problem domain, with Claude explicitly telling you who received it; and if a single message contains unrelated tasks, it splits them into separate independent threads. If its dispatch does not match your expectations, you can directly ask it to adjust.

In the demo, Claude recognizes these as three independent work streams and immediately generates three thread cards dispatched in parallel across the UI: the first task bisects a regression across a range of 7 remaining commits; the second task scans 23 PRs merged since v4.11 to summarize changes; the third task updates SDK invocations across 6 files. At this point, the right-hand Overview panel shows 3 threads in the Working state.

While each thread progresses independently, you do not need to re-orchestrate the overall state if a new thought pops up. For instance, half an hour later the user offhandedly adds in the main conversation: "oh and the release moved to Monday, make sure the notes say that". The coordinator automatically identifies which workstream this information belongs to and routes it directly to the thread drafting the release notes. Receiving the routed message in its own isolated session, the thread adjusts the release date to Monday (Sep 22) and shifts the code freeze reminder to Friday right on the spot—without disturbing the other two threads investigating code.

Deliverables upon task completion also follow distinct paths. The thread investigating performance pinpoints the root cause to an N+1 query in QuoteService, reverts it to a batched query, pushes a new branch to GitHub, and opens PR #4821; the main conversation immediately receives a completion report: "The p99 thread is done: PR #4821 is up (an N+1 in QuoteService, batched again) and CI is green."

When a thread hits a technical inflection point it cannot resolve autonomously, it halts automatically to await human input. After updating 6 files, the thread upgrading stripe-node runs contract tests; 41 of 42 tests pass, with the final one failing because the downstream webhook-lambda is still running on Node 18 (stripe-node v15 drops support for Node 18). Rather than guessing blindly or bypassing tests, the thread transitions its status to Waiting on you, providing trade-off recommendations between upgrading the Lambda runtime to Node 20 (recommended) or pinning stripe-node to v14.

Importantly, threads run by default in auto mode when the model supports it, executing the vast majority of tool calls without asking for confirmation. When a thread genuinely requires your approval, prompts appear exclusively inside that thread, and it will wait until you reply inside that specific thread; if you tell Claude to proceed within the project conversation, that instruction does not propagate down into the thread. Messages typed in a thread's dedicated input box reach it directly, whereas follow-up messages in the project conversation are only forwarded if Claude matches them to that thread. In the official demo, the user clicks into the stripe-node thread directly and submits their decision in its internal input box.

In the Overview panel to the right of the project conversation, thread statuses are clearly categorized into six groups:

• Ready for review: Threads with an open PR waiting for review;
• Waiting on you: Threads waiting for your reply or approval, or those that have failed;
• Working: Threads actively running;
• Landing: Threads whose PRs are approved or queued for merge;
• Idle: Completed threads that are idle and waiting on nothing;
• Resolved: Threads marked as resolved (marked manually by you, marked by Claude after you complete final steps such as merging a PR, or marked automatically after one week of inactivity).

If you use the desktop client, system notifications pop up whenever a thread errors, requires your input, or when Claude speaks in the project conversation, eliminating the need to constantly watch the screen; in web browsers, a badge indicator on the Overview button alerts you when threads are waiting on you.

Returning to that morning workflow, the four threads moved across these groups as follows:

Architectural Breakdown: Did It Just Port "Claude Tag" into Claude Code?

Following the release of redesigned Projects, one characterization circulated: "Projects brings the Claude Tag architecture to Claude Code, giving each project an agent to manage memory and dispatching subagents for tasks, enabling proactive action and scheduled runs."

Structurally, this characterization has merit, as the layering between the two aligns almost one-to-one:

• Intake vs. execution layering: In Claude Tag, each Slack channel has its own session handling top-level messages; when encountering tasks requiring investigation, tool execution, or extended dialogue, it launches a dedicated session in a Slack thread beneath the message. In Claude Code Projects, Claude in the project conversation likewise acts as the intake coordinator, while spun-off threads handle actual execution.
• Isolated sandboxes and lifecycle: In Claude Tag, each thread runs in an isolated ephemeral cloud sandbox; two threads in the same channel are separate sessions that do not share state directly, with sandboxes released when threads go quiet and reconstructed upon new replies. In Projects, each thread is similarly an independent cloud session working on its own git branch, with sandboxes paused between interaction turns and resumed upon continuation.
• Cross-task memory: Knowledge gained by Claude Tag in public channels is stored as workspace shared memory, while private channels store memory separately; in Projects, threads similarly share a single project memory.
• Scheduling and follow-up mechanisms: Claude Tag supports scheduled runs, tracks PRs, and takes action when they change; Projects similarly supports routines, while threads automatically monitor PR status and follow up with fixes.

However, official documentation and blog posts do not adopt the phrasing of "bringing the Claude Tag architecture to Claude Code"; in official docs, Claude Tag represents a product form better suited for "multiple people dispatching and steering together in a Slack channel." Differences between the two are outlined below; furthermore, the three concepts in that quote—an "agent to manage memory," "subagents," and "proactive action"—require qualification, detailed in the following three subsections.

Crucially, the fundamental difference lies in ownership. Claude Tag is built for teams, residing permanently in Slack channels (its recent update lets it read the whole channel before deciding whether to chime in), where anyone in the channel can assign tasks or steer in-flight work using a unified admin-configured service account.

In contrast, redesigned Projects in Claude Code is currently strictly personal: only you can assign tasks or view its threads; threads run using your personal GitHub push permissions and connectors linked to your claude.ai account, with no options to share thread transcripts.

On Memory: The Coordinator Is Not the Sole Writer

Describing it as "giving each project an agent to manage memory" is only half accurate. In Projects, project memory is not written to exclusively by the coordinator; inside the project conversation or within any thread, you can instruct Claude to remember or forget specific requirements, architectural decisions, or pitfalls. When correcting a thread's implementation, it is best practice to have Claude commit that correction to memory so subsequent threads start with that context. Additionally, Claude autonomously logs your coordination preferences (such as reporting frequency and concurrency preferences) into project memory.

Project memory captures long-term business context and decisions—for example, that a release moved to Friday, why an export feature was dropped, or whom to contact before modifying billing services.

Three things to keep in mind regarding project memory:

1. Viewable and maintainable anytime: Memory files reside under Project settings > Memory, listed under Auto memory, where you can inspect, edit, or delete files at will;
2. Independent from local memory and repository rules: It maintains separate storage from your local Claude Code auto memory and remains distinct from repository CLAUDE.md files. Repository-specific coding guidelines belong in CLAUDE.md, while project-level business context and decision logs belong in project memory;
3. Critical information must be committed to memory: To sustain long-running operations, the project conversation does not ingest the entire historical transcript; it operates solely on recent messages, recent threads, and project memory. Any context that must never be lost must be recorded into project memory.

An animated walkthrough from the official blog demonstrates how a project named Launch readiness evolves from Monday through Thursday: the release date, originally set to Oct 14 based on timeline.csv, gets postponed twice to Oct 21 and Oct 28, with each update synced into memory; when the user adds follow-up requirements like "Add pricing to it", the coordinator automatically attaches it to the existing Partner email thread; across several days, accumulated Results and Decisions stack neatly beneath the conversation.

On Execution Units: Threads Are Full Cloud Sessions, Not Lightweight Subagents

Calling task executors "subagents" causes conceptual confusion. In Claude Code's existing architecture, subagents refer to delegated workers spawned inside the same session that execute side tasks in their own context and return summaries back to the primary session.

Threads spawned in Projects, however, are fully featured, independent cloud sessions. Each thread maintains its own code copy and context window. When tackling larger tasks, each thread can internally invoke subagents, loops, and workflows to partition work and accelerate execution.

On Proactive Action: Trigger Scenarios and Hard Boundaries

The "proactive action" perceived by users operates within strictly defined triggers and operational boundaries:

• Initial exploration of your first project: After creating your first project, if you do not post a message immediately, Claude performs an initial autonomous pass: if readable repositories are connected, it may spin off a read-only exploration thread to inspect the code and suggest next steps; alternatively, it may draw on recent cloud sessions to generate Setup recommendations, suggesting repositories to attach, routines to create, and threads it can launch. This pass consumes your plan usage allowance.
• Routines: You can instruct Claude to place recurring work on a schedule as a routine, executing as threads within the project under the Routines tab; standalone routines created outside projects continue running independently as usual.
• Branch monitoring and self-healing: As long as a thread opens a PR, it proactively tracks that PR regardless of whether auto-fix is enabled in your other cloud sessions. If CI fails or review comments appear on the repository, the thread wakes up automatically, pushes remediation commits, and reports back only when checks pass and the PR is ready for your review.

When evaluating proactivity, keep the following safety and consumption rules in mind:

• No hard concurrency caps: The system spins up threads dynamically based on task requirements. Directives like "run at most two at once" in conversation are merely coordination preferences, not rigid system limits; enforcing strict concurrency limits across all threads from the outset requires defining them in project instructions. The only hard quota is a global limit of 200 new threads per day across all projects.
• Approval rules live in repository settings: Prompts requiring your approval appear strictly inside individual threads. To permit or block specific commands across all threads without prompting, you must define permission rules in the repository's .claude/settings.json, which only takes effect in single-repository projects.
• Rate limits auto-retry and consume subsequent windows: When a thread or project conversation hits 5-hour or weekly usage limits, the system retries automatically and resumes work once capacity resets—which will consume your next window's allowance without your explicit prompt. If you do not want it to draw from future windows automatically, click Stop inside the thread or Pause the entire project. (Threads launched via routines are an exception: they fail immediately upon hitting limits without retrying.)

Horizontal Comparison: How to Choose Among Five Parallel Modes in Claude Code?

A week earlier, Cursor also launched its own feature named Projects, similarly featuring a coordinator that plans and dispatches multiple agents in the cloud. Looking at Claude Code itself, there are currently five distinct ways to run multiple tasks concurrently.

Many developers conflate these concepts. Their core differences boil down to two factors: who manages task scheduling, and whether code runs locally or in the cloud:

Note that running multiple sessions or subagents concurrently multiplies token consumption rapidly.

Claude Code's cross-session messaging allows sessions you open manually to pass findings and state between one another, but deciding which sessions to open, who handles what, and when to wrap up still falls entirely on you. Redesigned Projects offloads the burden of launching sessions, delegating work, and monitoring progress entirely to Claude in the project conversation.

Projects excels at long-horizon work that outlasts a single session and continually generates new tasks: cross-repository initiatives, services with an ongoing influx of bug reports, broad feature builds or migrations exceeding single-session scopes, or non-coding document research (uploading files instead of attaching repositories, with threads placing deliverables into the Library tab). In the following four scenarios, alternative approaches are better suited:

• Single tasks manageable within one session (e.g., fixing a flaky login test): Launch a single cloud session directly;
• Tasks requiring tools or services accessible only on your machine (e.g., local databases, hardware emulators, APIs behind corporate VPNs): Use local sessions or run several concurrently via agent view; if the task only requires local files, upload them directly to the project;
• Recurring scheduled tasks requiring no back-and-forth dialogue (e.g., generating a weekly dependency report): Create a standalone routine;
• Multiple people assigning tasks and guiding Claude together in Slack: Use Claude Tag.

Usage: Opus by Default, Consuming Quota Faster Than Single Sessions

Under default settings, both the project conversation and all worker threads run on Opus; threads run on High effort by default, while the coordinator conversation runs on low effort.

Projects draws from the same plan quota as your other Claude Code sessions, but burns through usage significantly faster: each running thread is a complete session, meaning multiple parallel threads deplete allowance simultaneously; the project conversation consumes tokens reviewing thread reports and planning next steps; moreover, idle threads monitoring open PRs reactivate whenever CI breaks or new review comments arrive, consuming additional quota. Pro subscribers should anticipate reaching plan limits sooner on days with active projects. However, when a project has no running threads, no monitored PRs, and no incoming messages, idle projects consume zero quota, and archived projects incur no ongoing consumption.

To manage and optimize project usage:

• Inspect token consumption broken down by thread, model, and coordinator usage under Project settings > Usage;
• Sending follow-up messages to an old thread that has remained idle beyond the cache lifetime (1 hour cache lifetime within Pro and Max quotas) forces it to reread the entire conversation history; for new tasks, having Claude open a fresh thread is often far more token-efficient than waking a bloated legacy thread;
• Switch threads or the project conversation to smaller models or reduce effort under Project settings > General;
• Instruct Claude in the project conversation to launch fewer threads or answer minor queries directly in place rather than spinning off new threads.

Three Things to Configure Before Starting

Before handing a long-term project over, setup issues most frequently arise across GitHub permissions, available thread tools, and multi-repository configurations.

GitHub: Must Install the Claude GitHub App

When running Claude Code in the terminal, developers often authenticate with GitHub and obtain tokens via /web-setup. While that token allows regular cloud sessions to access repositories, it is insufficient for project threads. Running entirely in the cloud, project threads require the official Claude GitHub App installed on target repositories, and your personal GitHub account must possess push permissions; if the repository belongs to an organization enforcing SAML SSO, you must explicitly authorize organization-level single sign-on. Without the Claude GitHub App installed, threads fail before starting and will not launch.

Local Tools and Extensions Do Not Carry Over

Threads execute inside clean cloud environments and will not inherit local skills, MCP servers, plugins, or tools installed in your local Claude Code setup. Required tools and extensions must be provisioned via:

• Skills, subagents, and custom commands: Commit them directly to connected repositories (e.g., .claude/skills/, .claude/agents/, and .claude/commands/), which threads load automatically upon cloning; threads also automatically load skills enabled on your claude.ai account;
• Plugins: Add them under Project settings > Plugins, loaded whenever a new thread initializes;
• MCP servers: Threads access MCP tools via connectors configured on your claude.ai account, available across all threads without per-project setup. Crucially, the project conversation itself lacks connectors; tasks requiring connectors must be delegated to threads;
• CLI utilities and packages: Install them via the cloud environment setup script;
• Internal network access and environment variables: Configure domain allowlists, environment variables, and API credentials within the cloud environment settings for internal APIs, private package registries, or external services.

Multiple Repositories: In-Repo Permission Rules and Hooks Do Not Apply

Projects supports attaching multiple repositories, but configuration inheritance differs between single-repository and multi-repository setups.

When linking multiple repositories, each repository's CLAUDE.md, .claude/ skills, subagents, commands, and plugins enabled in individual settings.json files load normally; if two repositories conflict regarding a plugin, settings configured under Project settings > Plugins take precedence.

What fails to take effect are permission rules, hooks, and environment variables defined inside individual repository settings.json files—none apply in multi-repository setups, though hooks bundled inside enabled plugins still execute. This occurs because multi-repo threads initialize from the parent directory above all repository clones, ignoring repository-level configuration files.

In multi-repository projects, establish global policies inside project instructions and configure environment variables in the cloud environment settings. Note also that edits made to instructions, repositories, plugins, or environments in Project settings apply only to newly created threads, leaving existing running threads unaffected.

Current Limitations

• Platform and client constraints: Accessible exclusively on claude.ai/code, the desktop app, and Claude mobile apps; the terminal CLI is unsupported (the CLI's claude project command manages local directory state and is entirely unrelated), nor is it available through third-party platforms like Amazon Bedrock, Google Cloud Agent Platform, or Microsoft Foundry;
• Cloud execution only: Local sessions cannot join projects, and threads execute solely in the cloud. Official guidance indicates local workflow support is planned;
• Single-user ownership and rigid tenancy: Projects belong exclusively to the individual creator, cannot be shared with collaborators, lack transcript sharing options, and feature no organization-level governance during beta; furthermore, threads remain tied to their originating project and cannot be transferred or copied across projects;
• Uncommitted changes risk loss: Sandboxes pause between interaction turns and resume upon continuation; if a sandbox fails to restore, the thread restarts from a fresh clone, losing uncommitted modifications. Instruct threads on long tasks to commit and push changes incrementally to remote branches.

Summary: How to Kick Off Your First Long-Horizon Project

Redesigned Projects delegates session management, task routing, and progress tracking to the coordinator, shifting your primary focus to clarifying instructions, provisioning cloud environments, and verifying completed deliverables.

Before dispatching substantial workloads to a new project, verify setup following official best practices:

1. Draft project instructions: Take advantage of the 16,000-character instruction limit to brief every new thread. Specify target repositories and branches, PR naming conventions, required pre-completion validation (such as running make test and make lint and summarizing outputs in final reports), explicit bans against guessing or mocking missing dependencies/credentials, and actions requiring explicit in-thread permission. Place repository-specific guidelines inside the repository's CLAUDE.md.
2. Run a test task and inspect outputs: Dispatch a modest initial task or launch Claude's recommended setup threads; once finished, inspect how the thread reported its work and review branch diffs. If it made incorrect assumptions or encountered permission gaps, adjust instructions or cloud environments accordingly.
3. Review thread model and effort: Navigate to Project settings > General to review Thread model and Thread effort. New projects default to Opus with High effort across all threads, burning quota rapidly; consider dialing down effort or selecting smaller models based on task complexity.
4. Start with strict guardrails and relax progressively: Instruct Claude in the project conversation to propose threads for approval before execution, and cap simultaneous thread limits. Once several cycles confirm that decomposition and reporting meet expectations, remove these constraints.

Who Can Use It Now

• Now: Public beta rolling out initially to Pro and Max users who have run cloud sessions and have no legacy projects in claude.ai chat or Cowork.
• Shortly after: Users with legacy projects receive access slightly later to facilitate seamless migration.
• Over the coming week: Broadening to additional Pro and Max Claude Code users, followed by general Claude availability and Team/Enterprise plans.
• How to check your access: If Projects is missing from the claude.ai/code sidebar or the desktop Code tab, access has not yet reached your account; you can join the waitlist.
• Where to access: Web (claude.ai/code), desktop app, and Claude mobile apps on iOS and Android.
• What happens to legacy projects: They continue functioning normally and will be upgraded uniformly once the new experience rolls out across chat and Cowork.