What changed in Claude Projects on September 17, 2026, and what does it leave the customer to supply?
Anthropic rebuilt Projects around a coordinator that scopes a goal, delegates it to parallel cloud sessions called threads, reviews what they report and assembles the result, with a shared memory every thread reads and writes. The system does not approve its own work: auto mode runs a separate classifier model that blocks merging a pull request no human has approved.
What ships empty is the project instructions field, a 16,000-character brief where Anthropic’s documentation says the customer writes how a thread checks its own work before calling it done.
Questions as you read? Ask, or take the context files with you.
Where should we send it?
Sent ✓ Download it now →
The most important line in the launch is in the documentation, not the announcement
Anthropic’s documentation for the new Projects contains a sample project brief. The brief runs four bullets, and one of them reads: “Before you call work done, run make test and make lint and paste the summary lines in your final message.”
That is an acceptance standard. That single line decides whether a piece of automated work counts as finished. It appears in the docs as an example, inside a field that starts empty on every project you create.
The announcement that went out on September 17, titled “Projects redesigned: from folder to conversation,” did not mention it. Neither did the roughly twenty outlets that covered the launch within a day. They covered the coordinator, the parallel threads and the shared memory, which is the right list of features and the wrong end of the story.
The five context files.
Fill-in templates for what your AI should know, and the page that says where each one loads.
On its way. Check your inbox, or download it now →
What Anthropic actually shipped on September 17
The mechanics are worth getting exactly right, because two different products are being described in the coverage under one name.
This is Claude Code Projects, in beta, on Pro and Max plans. The Projects most people use in claude.ai chat have not changed and continue to work as they did. Anthropic says updated projects reach the rest of Claude, plus Team and Enterprise plans, after the Claude Code rollout finishes, and gives no date for it.
Inside a project, you describe a goal. In Anthropic’s words, “Claude scopes the request, delegates the work, coordinates parallel threads, reviews the outputs, and assembles the finished result.” Each thread is a full Claude Code cloud session running on its own branch and its own copy of the repository. Threads keep working after you close the laptop, and you can steer them from a phone.
The framing Anthropic chose for this is unusually direct about what it is asking you to become: “Brief Claude in the project the way you’d brief a chief of staff and it routes work to new or pre-existing threads.”
Three things sit underneath that. Every thread reads and writes a shared memory, which Anthropic says reduces the need for complex prompt engineering. A library collects both the files you upload and the artifacts threads produce. And when two threads touch the same code, the overlap resolves as an ordinary merge conflict on a pull request.
The eligibility rule carries an irony. The beta went first to Pro and Max subscribers who use cloud sessions and who have no existing projects on the web or desktop. The people with the most accumulated project context were last in line.
The AI Briefing
Tuesdays. 500+ leaders. No hype, just what works.
From folder to conversation, and what that swap actually costs
The old Projects was a container. You put custom instructions in it, uploaded a knowledge base, and started conversations inside it. Everything in it was passive and human-maintained: it sat there until you changed it.
The new one is a participant. It decides what becomes a thread, it runs them, and it writes to its own memory as it goes. Anthropic labels those files “Auto memory, because Claude writes them itself as it works in the project.”
That single swap, from a knowledge base you maintain to a memory that maintains itself, is the largest change in the release. It also drew the least coverage. A file you wrote is a file you can be held to. A file the system wrote about your business, while working on your business, is something else, and you find out what it says by going to look.
To be fair to the design, you can look. Project memory is readable, editable and deletable under Project settings, and you can tell Claude to forget something. The gate that is missing is the one before the write, not the one after.
The knowledge base was passive and human-maintained. The shared memory is active and machine-maintained. Everything else in the release follows from that.
This is the pattern we described when we argued that Claude is becoming an operating system in May. Persistent state, a filesystem, a scheduler. The redesign strengthens three of those components at once, which is a reasonable claim to make about a feature release and a boring one to build an article on. The interesting question is what the operating system does not supply.
The correction the coverage needs: Claude does not approve its own work
There is a reading of this launch, and I have seen it in more than one place, that goes: the model now does the work and grades its own homework. It is a satisfying sentence and it is wrong, and getting it wrong would cost the argument its credibility.
Threads run in what Anthropic calls auto mode, which is the built-in starting permission mode on Pro, Max and Team plans. Auto mode is not the absence of a check. Anthropic’s permission documentation describes it plainly: “In auto mode, a second model, the classifier, reviews actions instead of you.”
That classifier ships with a default block list, and the entries on it are the ones that matter here. It blocks force pushes. It blocks piping a download straight into a shell. It blocks production deploys. And it blocks “merging a pull request no human has approved, approving Claude’s own pull request, or disabling CI checks.”
So the shape of the system is a thread that does the work, a classifier that refuses the irreversible moves, a pull request that a person still merges, and a coordinator that assembles what comes back. The human gate on the output survives. Anyone writing that a thread can ship to production unsupervised has not read the permission docs.
What the coordinator reviews is narrower than it sounds. The documentation is careful about this: the project conversation “sees what threads report back, not every step they take.” It is reading summaries, not work. That is a sensible engineering choice with a consequence attached: the thing reading the summary is also the thing that produced it.
What ships empty
Here is where the release stops supplying and starts asking.
Project instructions are the brief every new thread starts from. They hold up to 16,000 characters, they live under Project settings, and they go to the threads and to the coordinator both. Anything in that field governs everything the project produces.
Anthropic tells you what belongs in it. The documentation says a useful brief covers five things, and two of them are the ones this whole article is about.
Read the third and the fifth items again. Those are a quality bar and an approval gate, described accurately, placed correctly, and left blank.
The worked example Anthropic provides is better than most quality documentation a mid-market company has written for its own staff. It tells threads to run the test and lint commands and paste the summary lines before calling work done. It tells them that if they cannot reach a repository, a secret, an API or a connector, they should say exactly what is missing in their first message and stop, and it adds: “Don’t substitute, mock, or guess.” It tells them not to merge, force-push or change CI configuration without asking.
Every one of those is a judgment about what your company considers acceptable. None of them can be defaulted, because they are not facts about software, they are facts about you.
The acceptance standard is named. It is named as your homework.
Where your rules stop and Anthropic’s keep going
The gap that makes this more than a truism is not in the instructions layer. The gap sits in the enforcement layer, and it opens at a specific and slightly absurd threshold.
Claude Code lets you write real enforcement into a repository: permission rules in .claude/settings.json that allow some commands without asking and block others outright. In a project, the documentation says those rules apply “only in a project with one repository.”
Now set that against the use case the launch leads with. Anthropic’s own example is one goal across many repositories: connect your API, web and mobile repos, retire a deprecated endpoint, one thread per repo. The documentation’s example is bringing every service up to a new lint config. Multiple repositories is not an edge case here. It is the headline.
So in the flagship scenario, your permission rules stop binding. Anthropic’s classifier keeps running, because it is configured at the account level and not by your project. The enforcement that survives the multi-repository setup is Anthropic’s, not yours.
Two honest qualifications belong here. Hooks that come from an enabled plugin still run in a multi-repository project, and a PreToolUse hook can deny a tool call, so a narrow customer-side enforcement path does survive.
Prose is not purely advisory either. The auto-mode documentation says the classifier reads the same CLAUDE.md content Claude loads, so an instruction like “never force push” in a repository steers the classifier too. Whether the project instructions field reaches the classifier is stated nowhere, and I am not going to assert it in either direction.
One further reading belongs here, flagged as a reading rather than a fact. The classifier takes its configuration from your user-level or managed settings, and the documentation says it does not read auto mode settings from a project’s .claude/settings.json. Threads separately pick up nothing from the Claude Code setup on your machine. Managed settings are a Team and Enterprise mechanism, and Projects is Pro and Max only.
Put those together and a thread’s classifier appears to run on Anthropic’s defaults, with no documented way for a customer to tune it. That is an inference across three documents, not a sentence Anthropic wrote, and it is the first thing I would test in the product.
A related point that the parallel-threads framing obscures: this is still one person’s system. The documentation states that a project belongs to one user, cannot be shared, and that “there are no organization-level controls for projects during the beta.” Whatever standard you write, you write it for yourself. No mechanism exists to hold a team to it.
The part built for work that is not code, which nobody covered
Every outlet filed this as a developer story, and the announcement invites that reading: the worked examples are endpoint latency and a deprecated API. The documentation says something broader, and it says it plainly.
Among the kinds of work a project suits, Anthropic lists “work that isn’t code,” and gives as the example a folder of contracts or a support-ticket export you keep returning to with new questions, such as finding the ten most common integration mistakes in a set of tickets. You upload the documents instead of adding a repository, and threads deliver each write-up as a file on the project’s Library tab. Google Drive folders count as an input alongside uploaded files and folders.
Anthropic has just described an analyst pool for document work, pointed at material a mid-market company has sitting in a shared drive right now. It is the first thing in Claude Code that a non-engineering leader could plausibly run without an engineer, and in a day of coverage I could not find a single piece that mentioned it.
The limits are real and they are stated. Threads reach GitHub repositories and the files you upload, and nothing that lives only on your machine or behind your network, though Anthropic says local execution is coming very soon. Projects are not in the terminal CLI, and not available through Amazon Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry. A thread’s sandbox pauses between turns, and if it cannot be resumed the thread restarts from a fresh clone, so uncommitted work can be lost.
Notice what the document path does to the argument of this article. On a repository, a pull request is a natural gate: somebody merges, and the classifier will not let a thread approve its own. On a folder of contracts there is no pull request. The deliverable is a file that appears on a tab. The structural check that makes the code path safe does not exist on the document path, and the only thing standing in its place is the acceptance standard you wrote in project instructions.
So the use case with the widest business reach is also the one where the blank field matters most.
The five context files.
Fill-in templates for what your AI should know, and the page that says where each one loads.
On its way. Check your inbox, or download it now →
This is not an Anthropic problem, and that matters for what you do about it
It would be easy, and lazy, to file this as a gap in one vendor’s product. The category does not support that.
OpenAI’s workspace agents put guardrails, approvals and human checkpoints in the customer’s hands: they are things you add. Google’s Workspace Studio lists confirmation for externally-shared steps among additional admin settings, which means opt-in. Microsoft is the real exception, shipping built-in graders in Copilot Studio including a general quality grader that runs with no configuration at all.
The strongest evidence, though, comes from Anthropic itself. Its Managed Agents product has an outcomes feature where a separate grader evaluates the artifact in its own context window and loops until the work passes. The documentation on it contains a flat, four-word line: the rubric is required. Developer-supplied. No default offered.
That is the company stating its own position on where the standard comes from, in a different product, in the same month, while the launch coverage looked the other way.
Across the category the acceptance standard is customer-configured. Anthropic is not an outlier here, only the clearest case, and its own API documentation says so out loud.
The practical consequence is that no amount of waiting fixes this. No release is coming that ships a definition of good for your business, because the thing being defined is not the software.
What this changes about the work
We argued in April that AI agent sprawl is a design problem rather than a counting problem, and that the platform responses of the time fixed discoverability and governance while leaving four things untouched: skills structure, context architecture, governance rules and learning loops. That claim needs qualifying now. Shared memory is a context-architecture primitive. Memory that accrues from execution is a learning-loop primitive. Anthropic has shipped narrow versions of two of the four, inside the vendor, and any honest reading has to say so.
What has not moved is the other two, plus the arbitration question nobody has answered: when two threads write conflicting things into a shared memory, whose version is right, and who decides.
We also argued, when Anthropic’s engineers said to stop building agents and build skills, that the layer you treat as the asset determines whether the system compounds. A reader who knows that piece will notice that Anthropic’s headline feature is now a fleet of parallel threads, and might reasonably ask whether AI skills versus agents aged badly.
I do not think it did, and the reason is visible in the architecture. This is one coordinator, one shared memory, one shared library, with disposable runtimes underneath, and not twelve independently-contexted agents accumulating separate knowledge. The threads are cheap and forgettable on purpose. The memory is the asset. That was the argument.
The place the ground genuinely shifted is the one we should be most careful about. Our position has been that most AI implementations are static and that learning loops have to be designed in. Anthropic just shipped a learning loop as a platform default.
The distinction that remains is narrower than it was, and it is a single thing: the gate. In the operating system we run for our own firm, a proposed change to how the system works goes into a queue and a person approves it before it takes effect. Auto memory writes itself, and you audit afterward if you remember to. That is now the whole of the distinction. That difference still matters, and it now runs on one axis where it used to run on four.
This is also where the connection to verification loops stops being theoretical. The argument there was that prompting is a transitional skill and the durable one is defining what good looks like. The redesign turns that into a literal text field with a character limit.
The cost question, because parallel is not free
One more thing belongs in any honest read of this release, and it comes from Anthropic’s own documentation rather than from critics.
A new project runs Opus everywhere by default, with high effort for threads and low effort for the coordinator conversation. Each running thread is a full session. Anthropic writes that a project “uses your limits faster than a single session does, and on a Pro plan in particular you should expect to reach your limit sooner on days you run one.” The enforced ceiling is 200 new threads per day across your projects.
A subtler line item sits underneath. A thread that has opened a pull request keeps watching it, with auto-fix on whether or not auto-fix is on for your other cloud sessions, and it wakes up and spends again when CI fails or a review comment lands. You stop that by asking the thread to stop watching.
And if you tell Claude to run at most two threads at a time, the documentation is candid about what that is worth: those preferences are “instructions Claude keeps to, not enforced settings, so a thread limit you give this way isn’t a hard cap.”
This is the live instance of the pattern we mapped in how AI token costs multiply. Agentic work multiplies consumption because the number of model calls stops being a function of how many questions you asked. Parallel by default multiplies it again. The controls Anthropic gives you are real, four separate model and effort settings plus a per-project usage view, and they are controls you have to go and set.
What to do this month
If you are on Pro or Max and you have a repository-shaped body of work, this is worth running. Not because the coordinator is magic, but because it surfaces, quickly and cheaply, whether your company can articulate what finished means.
Write the project instructions before you start the first thread. Not after the first bad output. The field is the highest-leverage 16,000 characters in the product, it governs both the threads and the coordinator, and it is the only place your standard exists.
Put the acceptance standard in concrete commands where you can. “Run the test suite and paste the summary” is enforceable prose. “Maintain high quality” is not, and a classifier cannot make it so.
Scope the pilot to one repository. This is the counterintuitive part, and it follows directly from the enforcement gap: single-repository is the only configuration where your own permission rules and hooks actually bind. The multi-repository setup is the more impressive demo and the weaker governance story.
Then read the memory. Open Project settings after a week of work and read what the system decided to remember about your business. If nothing in there surprises you, the project was too small to learn anything. If something in there is wrong, you have just found out what an ungated learning loop costs, on a small bill instead of a large one.
Where outside help earns its place is narrower than a vendor would like it to be. Nobody needs a consultant to turn on a beta.
What is genuinely hard from the inside is writing an acceptance standard that survives contact with the people who disagree with it. The argument about what good means is a political argument inside a company before it is a technical one, and the person running the pilot usually cannot settle it alone. That is the work in a CompanyOS engagement, and the test to apply to us or anyone else is simple: at the end, do you own the document, or do they?
The gate that survived this release is the human one, the pull request nobody merges for you.
The design principle underneath all of this is the one we keep coming back to. That gate is not a limitation the next version will fix. It is the part worth defending.
Your Project Instructions, First Draft
Paste this into any Claude conversation with a real body of work in mind. You get back a draft brief you can put straight into the project instructions field, structured on the five things Anthropic says the brief should cover.
Context: I am setting up a Claude Code project to coordinate a body of work. A project runs parallel threads, each a separate cloud session on its own branch, and they all start from a shared instructions field of up to 16,000 characters. I need to draft that field. Ask me for the goal, the repositories or documents involved, and who has to approve what, then write the brief.
Step 1. Establish the purpose and the territory: Ask me what the project is for in one sentence, which repositories or document sets it touches, which branch threads should start from, and how pull requests should be named. Do not proceed until you have all four.
Step 2. Draft the acceptance standard as commands, not adjectives: Ask me how I currently know a piece of this work is finished. Convert every answer into a specific instruction a thread can execute and report on, such as a test command to run and paste the output of. If I give you an adjective like “clean” or “production ready,” push back and ask what someone actually runs or reads to check it.
Step 3. Write the failure behavior: Draft the rule for what a thread does when something it needs is missing: a repository, a credential, an API, a connector. The default should be to name exactly what is missing and stop, with no substituting, mocking or guessing.
Step 4. Write the escalation rule: Ask me which actions need my go-ahead before they happen. Draft those as explicit prohibitions with the escalation path attached.
Output: A project instructions brief under 16,000 characters, organized as purpose, territory, acceptance standard, failure behavior and escalation, with every acceptance item written as something a thread can run and report rather than a quality adjective.
The prompt gets you a competent first draft in one sitting. What it cannot do is settle the disagreement you will discover while writing step 2, because that argument is between people and a prompt cannot hold it for you. If that is where you stall, see where you stand.
Sources
- Projects redesigned: from folder to conversation (Anthropic, September 17, 2026) supports the coordinator sequence, the chief-of-staff framing, shared memory, the library, the thread-per-branch architecture and the beta eligibility terms.
- Let Claude coordinate ongoing work with Projects (Anthropic documentation) supports the project instructions field and its 16,000-character limit, the five items a brief should cover, the worked example, the single-repository permission limit, the 200-thread daily ceiling, the Opus and effort defaults, auto memory, auto-fix on thread pull requests, the absence of organization-level controls, and the non-code use case.
- Choose a permission mode (Anthropic documentation) supports auto mode as the built-in starting mode on Pro, Max and Team, the classifier as a second reviewing model, and the default block list including merging a pull request no human has approved.
- Configure auto mode (Anthropic documentation) supports the classifier reading the same CLAUDE.md content Claude loads, and that it does not read auto mode settings from a project’s
.claude/settings.json. - Define outcomes (Anthropic documentation) supports the separate grader looping until the work passes, and the requirement that the rubric is developer-supplied.
- What are projects? (Anthropic support) supports the description of the previous Projects as custom instructions plus an uploaded knowledge base.
- Claude Code Projects runs parallel agents on Opus by default (Marcus Schuler, implicator.ai, September 18, 2026) first reported that permission rules, hooks and environment values from each repository do not apply in multi-repository projects.
- Introducing workspace agents in ChatGPT (OpenAI) supports guardrails, approvals and human checkpoints as customer-added configuration.
- Custom graders in Copilot Studio (Microsoft) supports built-in graders including a general quality grader that runs without configuration.
- New enterprise security controls for Workspace Studio (Google Workspace Updates, August 17, 2026) supports end-user confirmation for externally-shared steps being an opt-in admin setting.
Frequently Asked Questions
What changed in Claude Projects in September 2026?
On September 17, 2026, Anthropic released a redesigned Projects experience in beta for Claude Code. Instead of a folder holding instructions and files, a project is now one conversation where Claude acts as a coordinator: it scopes the request, delegates work to parallel cloud sessions called threads, reviews what they report and assembles the result. Every thread reads and writes a shared project memory, and a library collects both uploaded files and the artifacts threads produce.
Is this the same as Claude Projects in the chat app?
No, and the distinction matters. The redesign launched for Claude Code Projects on Pro and Max plans, available at claude.ai/code, in the desktop app Code tab and in the mobile app. Existing Projects in claude.ai chat and Cowork continue to work as they did. Anthropic says updated projects will reach the rest of Claude, plus Team and Enterprise plans, after the Claude Code rollout, without giving a date.
Does Claude approve its own work in the new Projects?
No. Threads run in auto mode, which Anthropic’s documentation describes as a second model, the classifier, reviewing actions instead of you. Its default block list includes merging a pull request no human has approved, approving Claude’s own pull request, and disabling CI checks, along with force pushes and production deploys. Threads open pull requests and a person still merges them.
What are project instructions and why do they matter?
Project instructions are a field of up to 16,000 characters, set under Project settings, that is sent to every new thread and to the coordinator conversation. Anthropic’s documentation says a useful brief covers what the project is for, where the work happens, how a thread checks its own work before calling it done, what to do when something is missing, and what needs your go-ahead first. The field starts empty, so the acceptance standard for everything the project produces is written by the customer.
Do my permission rules apply in a Claude project?
Only in a project with a single repository. Anthropic’s documentation states that permission rules and hooks in a repository’s .claude/settings.json apply “only in a project with one repository,” which means they stop binding in the multi-repository setup the launch advertises. Hooks provided by an enabled plugin still run in multi-repository projects, and a PreToolUse hook can block a tool call.
How much of my usage does a Claude project consume?
More than a single session. A new project runs Opus everywhere by default, with high effort for threads and low effort for the coordinator, and each running thread is a full Claude Code session. Anthropic enforces a limit of 200 new threads per day across your projects and warns that Pro users in particular should expect to reach their limit sooner. A thread watching a pull request also wakes and spends again when CI fails or a review comment arrives.
Can a team share a Claude project?
Not during the beta. Anthropic’s documentation is explicit: a project has a single owner, it cannot be shared with another user, and no organization-level controls exist for projects while the beta runs. Team and Enterprise availability is planned but undated, so any standard you write in project instructions currently applies only to your own work.
Does this only work for code?
No. Anthropic’s documentation describes non-code use explicitly, such as a folder of contracts or a support-ticket export that you upload instead of adding a repository, with threads delivering each write-up as a file on the project’s Library tab. Google Drive folders are supported alongside uploaded files. Threads cannot reach files or tools that exist only on your machine or behind your network, which Anthropic says is coming.
