›_ Claude Code Issues
Claude Code Issues / #101369

[BUG][REGRESSION] Broken Projects upgrade wiped out classic projects with no no opt-out

Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 0 comments · opened Oct 11, 2026

Summary

This is not a cosmetic redesign. My classic claude.ai chat projects, which I used as sealed folders of separate private conversations with their own instructions, were converted to the coordinator-based Projects without my consent, without warning and without any way back. A working feature I pay for on the Max plan was taken away and replaced with an agent system that is slow, unreliable and supervises every conversation in the project. Concretely:

  1. Old project chats now also appear in the main sidebar, mixed in with standalone chats, with no project label. You can't group or filter by project.
  2. A project now opens on a coordinator conversation, not on a list of chats. New work inside the project has to start through the coordinator.
  3. The coordinator can see every thread in the project. Chats that used to be separate are no longer private from it.
  4. Replying to an old chat silently turns it into a coordinator-managed thread. The coordinator notices it and posts about it in the main project chat.
  5. The coordinator gave wrong information about how the project itself works.
  6. There is no setting to opt out, revert, or keep classic projects.

Anthropic's announcement and Help Center promise that existing chat projects "keep working as they do today". That promise is meaningless once the upgrade lands: the classic behaviour is gone entirely, nothing explains what happens to existing chats, and the same complaint has already been closed as "not planned" without a single maintainer reply (#99128). Users are left with no recourse at all.

Environment

  • Plan: Max 20x
  • Surface: claude.ai web (Helium / Chromium), macOS; the same layout shows in the Claude desktop app
  • Date observed: 2026-10-12
  • Affected projects: all three of my classic chat projects (all now show the coordinator layout)

Steps to reproduce

  1. Have a classic chat project with several chats and custom instructions. My use case was separate chats per topic, for in-depth, private conversations.
  2. After the upgrade, look at the sidebar. The project's chats are listed under "Ungrouped" alongside unrelated standalone chats, with no project label. "Group by" has no Project option, and Custom groups only change how the sidebar looks: a chat in one gets no project instructions and no isolation.
  3. Open the project. It lands on a coordinator chat. The old chats appear in a side "Threads" panel under "Idle".
  4. Ask the coordinator in the project chat: "List the threads in this project, and say whether I can open an old chat thread and message it directly without going through you." Coordinator's answer: the project has two threads; the three old chats "aren't threads yet"; an old chat "has to be turned into a thread first, and I'm the one who does that."
  5. Open one of the old chats from the Threads panel. It opens read-only in a side pane, ending with "End of original chat · Reply to continue", with a box labelled "Reply to start a new thread…".
  6. Reply there. The reply goes through and the thread's Claude can read the whole old conversation. But the chat is now a thread, the box changes to "Steer this thread…", and the coordinator posts a card about it in the main project chat, then corrects itself: "I was wrong. You just continued 'Prompt engineering' as a thread yourself, without me, and its Claude can read the whole old conversation."
  7. Earlier in the same project, the coordinator confirmed: "I can see what's written in every thread, even when I stay out of it, so threads here aren't private from me the way your old project chats were", and "Every new thread starts through this chat."

Expected

  • Upgrading a project doesn't remove the classic model without consent: an opt-out, a "keep as classic project" option, or a revert.
  • Chats belonging to a project stay grouped under that project in the sidebar (or "Group by → Project" is available), and aren't dumped into "Ungrouped".
  • Chats inside a project can stay isolated, one-to-one conversations with the project's instructions, without a supervising agent that reads them and must start every new chat.
  • The coordinator gives accurate answers about how its own project works.
  • Documentation explains what the upgrade does to existing chats before it happens.
  • Existing chats can be moved into a project, as before.
  • Voice conversations work inside projects.

Actual

  • Classic project behaviour is destroyed the moment a project is upgraded. There is no opt-out, no revert and no warning.
  • Project chats are mixed into the global sidebar with no label.
  • Every new chat in the project has to go through a coordinator that reads every thread. Conversations that were private are now under permanent supervision.
  • Continuing an old chat silently converts it to a thread, and the coordinator watches and comments on it.
  • The coordinator first stated that old chats couldn't be messaged without it, which was false.
  • Existing chats cannot be moved into a project at all. Upgraded projects don't accept chats, only threads started inside them. Also reported in [#100382](https://github.com/anthropics/claude-code/issues/100382).
  • Voice conversations are not supported inside projects. You cannot start one there.
  • Chats that were already in a project when it was migrated are stuck permanently under "Idle" in the Threads panel, even though they aren't idle threads. There is no way to move them to "Resolved" or clear them.

Impact

This upgrade removed the only feature that made Claude usable for serious, private, conversational work. Projects were the only way to keep topic chats separate and private with their own instructions. I used them as sealed folders: each topic's context, memory and instructions kept apart from other topics and from global memory, so unrelated subjects never polluted each other.

The new Projects are not a replacement for the old ones. They are a completely different feature that has nothing to do with what classic projects did, unless the work is coding. Classic projects worked like folders, and they simply stopped existing, taking away functionality that many users like me relied on. Some of mine were essential to my work: I relied on their custom instructions, their isolation, and my Cowork workflows built on them. None of that is supported anymore. Instead I'm forced to ask a coordinator to spawn a thread, wait a long time for it to respond, and accept that the coordinator stays in the loop for everything. That is nothing close to what was taken away. Even for coding, the one use it fits, it is incredibly confusing and, for all the reasons in this report, unusable. Removing classic projects for this was a terrible decision, and the replacement is terribly implemented.

After the upgrade:

  • Everything in a project runs under a supervising agent with shared project memory.
  • The only remaining way to avoid cross-topic context bleed is to turn memory off entirely, which costs memory everywhere else.
  • The project interface is completely unusable, even for an experienced power user. It is a pile of redundant elements that duplicate each other: a coordinator chat, thread cards inside that chat, a Threads panel with Idle/Resolved sections, a library, and the global sidebar, all showing the same chats over and over in different places, with no clear single place to see or manage anything.
  • My deep, meaningful conversations, which were kept organized by project, are now dumped into one ungrouped list, with no isolation and exposed to global memory, side by side with throwaway one-question chats like "What's the weather like?". I have no way to separate them, protect them, or move them back into a project. For a person with OCD traits, losing an order I deliberately built and kept is not a minor inconvenience; it makes the product genuinely distressing to use.

Nobody was asked and nothing warned that this use case would be removed. For a paid product, silently taking away a working feature and putting an agent between the user and their own private conversations is a serious breach of trust.

Coordinator and thread problems

The system that replaced classic projects is not ready to replace anything. Several of the failures below have already been reported by other Projects users since the September 17 rollout. This is a pattern, not an edge case.

  1. The coordinator gave wrong information about its own project. Asked whether old chats can be messaged directly, it said the three old chats "aren't threads yet" and that an old chat "has to be turned into a thread first, and I'm the one who does that". The Threads panel already listed all three under "Idle". When a reply was sent directly in one of them, the coordinator corrected itself: "I was wrong."
  2. Replies are slow for trivial requests. A one-line answer from the coordinator showed a "Composing" indicator for about 20 seconds. The Sonnet 5.5 Medium thread was still showing an activity spinner ("Levitating 20s") after it had posted its one-line reply.
  3. Threads are very slow regardless of model. Even Sonnet 5.5 at medium effort is far slower inside a thread than in a normal chat or Claude Code session. Threads hanging outright is reported in [#99091](https://github.com/anthropics/claude-code/issues/99091) ("very common, 1/3 threads").
  4. The coordinator doesn't understand its own role. The coordinator, which is suggested to run at low effort, doesn't know where it is, what it is, or what features it has (see item 1).
  5. Threads don't report back. When a thread finishes, the coordinator usually isn't told and doesn't know what to do with the result. Same in [#98355](https://github.com/anthropics/claude-code/issues/98355) (the coordinator "never relays back" thread problems) and [#95784](https://github.com/anthropics/claude-code/issues/95784) (blockers and questions don't surface on the orchestrator).
  6. Work isn't split. Given several separate issues, the coordinator often puts them all into one thread instead of starting a thread per issue.
  7. The coordinator loses track when several threads are running. Thread status shown to the user is wrong too, and per-thread to-do lists are never up to date ([#98355](https://github.com/anthropics/claude-code/issues/98355)).
  8. The coordinator can't stop threads. It reports that it has stopped a thread, but a thread running a multi-step plan keeps going until stopped manually. Same in [#99091](https://github.com/anthropics/claude-code/issues/99091) ("I have to kill the thread").
  9. Helpers are invisible. Thread sessions say they can launch helpers or subagents, possibly on other models such as Haiku. None of this is shown anywhere. Settings only let you pick the coordinator and thread models, so it's impossible to tell how many helpers are running, which models they use, or whether any are running at all.
  10. It doesn't work even for the coding it was built for. Not one task I have tried through the coordinator has worked. Delegating through it is slower and more confusing than writing the code myself.
  11. It burns tokens for nothing. Coordinator and thread runs consume a very large amount of usage while producing no working result. This is a raw, unfinished feature shipped as a replacement for one that worked.

Expected for the coordinator and threads

  • The coordinator answers accurately about its own project, threads and capabilities.
  • Threads report completion to the coordinator, and the coordinator acts on it.
  • Separate issues are split across threads.
  • Stopping a thread through the coordinator actually stops it.
  • All agents working in a project are shown: helpers and subagents, their models and their status.
  • Thread response speed is comparable to the same model outside Projects.

Related

Loss of classic projects and grouping

Coordinator and threads

View original on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →