Claude Code threads collide as ordinary merge conflicts

{"stayedShort": false, "template": "A", "html": "

When two of Claude's threads touch the same code, nothing clever happens: the overlap comes back as a merge conflict, like any other pull request. That detail sits inside the reworked projects in Claude Code, which <a href=\"https://claude.com/blog/projects-redesigned\">Claude</a> put into beta today, where you describe the work and a coordinator scopes it, delegates it to parallel threads, reviews the outputs and assembles the result.

\n

At a glance

\n

\n
• In a Claude Code project you set a goal and connect a repo or context, and a coordinator scopes the request, delegates it to threads, reviews the outputs and assembles the finished result.
\n
• Each thread is a full Claude Code cloud session on its own branch and copy of the repo, and a thread can split its own assignment further using subagents, loops and workflows.
\n
• Because several full sessions can run at once, projects reach usage limits faster, and threads run only in the cloud today, with local runs dated no more precisely than \"coming very soon\".
\n

\n

If you have not been following Claude Code, steering it from a phone is not the new part. According to Claude Code's documentation, a Remote Control feature already connects claude.ai/code or the Claude mobile app to a session running on your own machine, with the web and mobile interfaces described there as \"a window into that local session\". The same documentation says the connection is built to survive interruptions: if the laptop sleeps or the network drops, Claude Code reconnects when the machine comes back, queuing messages and permission prompts in the meantime.

\n

A checkout p75 latency goal turns into PRs in parallel threads

\n

The first example in the announcement is a performance job. You configure a project, set a goal to reduce your app's checkout p75 latency, then ask Claude to profile each endpoint, test optimizations and open pull requests in parallel threads. Managing that spread of work used to mean dividing it yourself, juggling handoffs and stitching the results back together.

\n

The second is a migration. Connect your API, web and mobile repos, set a goal to retire a deprecated v1 endpoint, and Claude creates a thread per repo to migrate the callers, run the tests and open PRs, then tells you which ones need to merge first. You can steer progress throughout, including from your phone, and the work continues after you step away from the computer.

\n

Each thread is a cloud session on its own branch and copy of the repo

\n

Starting a project means picking a goal plus the repo or context. Claude then suggests work it can pick up right away, and you configure the project's cloud environment, connectors, plugins, instructions and model. You watch progress in the main project chat, or open an individual thread to examine and steer the details.

\n

Under the hood, each thread is a Claude Code cloud session working on its own branch and copy of the repo. The announcement's framing is that you brief Claude in the project the way you would brief a chief of staff, and it routes work to new or pre-existing threads. With repositories connected, a thread opens pull requests and runs your tests; with documents, it reads them and drafts.

\n

The coordinator keeps the work organized, but it does not merge for you: if two threads work on the same code, the overlap resolves as an ordinary merge conflict. Each thread can also split its delegated work into pieces using subagents, loops and workflows, so large assignments finish faster.

\n

Claude remembers that the release moved to Friday

\n

Projects are aimed at work that takes longer than one reply and has more than one part. Every thread now writes to and reads from a shared memory, which the announcement says cuts the need for complex prompt engineering. The examples are mundane and useful: that the release moved to Friday, why the export was dropped, who to check in with before touching the billing service.

\n

Memory also covers how you like to be worked with. You can ask Claude to change how often it checks in, how frequently it starts new threads, and how detailed each update should be. Alongside memory, a project now has a library that collects the files you add and the artifacts Claude produces, so new work starts from past efforts instead of from scratch.

\n

The beta opens to Pro and Max users with no existing projects

\n

Access starts narrow. Today it is select Claude Pro and Max subscribers who use cloud sessions in Claude Code and do not have any existing projects on web or desktop. Over the coming week, access widens to more Claude Code users on those plans, and updated projects across all of Claude, plus Team and Enterprise, come after that. Pro and Max users without access can join a waitlist.

\n

Existing projects on Pro and Max keep working as they do now, and will be upgraded as the rollout reaches chat and Cowork. Because a project can run several full Claude Code sessions at once, it can reach usage limits faster than a single session would; there is project-specific usage to check, and you can pick the model and effort levels for the coordinator chat separately from the worker threads.

\n

What the announcement does not give is a ceiling: how many threads a project can run at once is not stated, nor what makes a subscriber one of the \"select\" ones in the first wave. Local execution, alongside your local tools and behind your network, carries no date beyond \"coming very soon\". In our view the merge-conflict answer is the honest part of the design, since the coordinator organizes the work without pretending it can untangle two threads that edited the same file.

\n

When threads reach your own machine

\n

The next dated checkpoint is vague by design: more Claude Code users on Pro and Max over the coming week, then the rest of Claude along with Team and Enterprise, then the upgrade of existing projects as the rollout reaches chat and Cowork. No calendar date is attached to any of those steps, and none to local threads either. Whether the phone-side steering behaves the same once a thread runs behind your own network is not addressed.

"}