[FEATURE] Subfolders / nested organization within a Claude.ai Project (web, desktop, mobile)
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Surface: Claude.ai Projects (web, desktop, and mobile chat) — NOT the Claude Code CLI. Filing here as the public tracker; please route to the Claude.ai team. (Flagging explicitly because a prior Claude.ai request, #51040, was closed as "not related to Claude Code," and the Feature Category options below are Code-centric.)
A Claude.ai Project has no organization below the Project itself. As a Project accumulates conversations — especially when Claude.ai is used alongside Claude Code for planning and review — they pile into one flat list with no way to group them. Users end up tracking in external tools the very conversations that should be organizable in-product.
"Just use separate Projects" doesn't solve it: related sub-threads routinely share context, artifacts, and a knowledge base that surface in one chat and matter in another. Projects are isolated from one another, so splitting work across multiple Projects breaks that shared context. The natural unit is one Project with internal structure — not many disconnected Projects.
Proposed Solution
Allow nested subfolders inside a Project to group conversations (and ideally artifacts) hierarchically — the way any OS file manager has for decades — while the Project's shared knowledge base and instructions continue to apply across ALL subfolders (one shared context, organized).
How this differs from existing requests: this is the same underlying need already raised on the Code side (e.g. #64354's request to "add a level of hierarchy underneath" the session sidebar), applied to the Claude.ai Projects surface, which is currently uncovered. Please treat it as related but distinct — same idea, different surface — rather than folding it into the Code-sidebar threads (#59016, #68171, #66877).
Alternative Solutions
- Separate Projects per sub-topic — loses the shared knowledge base/context that is the whole point of a Project.
- External trackers (notes apps, docs, spreadsheets) — defeats in-product organization and adds maintenance overhead.
- Paid third-party browser extensions that bolt nested folders onto Claude conversations (e.g. Toolbox for Claude, up to 5 levels; AI Toolbox) — these run only on claude.ai in a desktop browser, NOT in the desktop or mobile apps, which is exactly why a native feature would matter.
Priority
Medium - Would be very helpful
Feature Category
Other
Use Case Example
- I run one Project for a multi-workstream effort with several parallel threads (e.g. planning, research, drafting, review).
- Today every chat lands in one flat list inside the Project, so finding the right one means scrolling and guessing.
- With subfolders I would group them (e.g. "Planning", "Research", "Drafts"), each thread findable at a glance.
- The Project's shared instructions and knowledge base would still apply across all of them — organized, not fragmented across separate Projects.
Additional Context
Illustrative mockup attached below (information architecture only — not a proposed visual design).
<img width="3138" height="3500" alt="Image" src="https://github.com/user-attachments/assets/08fc3762-2229-4714-8cb3-2fab8da96a47" />
Independent demand: in the r/ClaudeAI "What Claude features do you want?" thread, a user requested "Topics within Projects" (group a Project's chats into topics) and noted they came looking for how to file it — i.e. it was never formally submitted; others in the same thread asked for project-chat folders and per-project chat separation.
Prior art: nesting is a long-solved problem — graphical folders date to the Xerox Star (1981, ~45 years), and the underlying nested-directory concept is older still (Multics/Unix, late 1960s).
11 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
The classifier's duplicate finds actually make the case better than I could. #36866 and #63710 are the same request as this one — organizing Claude.ai conversations into folders; #63710 specifically asks for conversations grouped under their Project and a nestable folder system. Both are closed as not planned and labeled
invalid — not related to Claude Code, and #36866's author closed it himself with "Oops, filed in the wrong repo." The bots on those threads in turn surfaced still more of the same: #35431, #22617, #11408, #38226.So this is a documented pattern, not a one-off: the same Claude.ai feature request keeps getting filed here, auto-labeled out of scope, and closed — by users who, like me, couldn't find anywhere else to put it. Claude Code has
/bugand this tracker. Yet, the Claude.ai apps (web/desktop/mobile chat, Projects) have no comparable public, trackable feature-request intake. Discord and Reddit are community spaces, not a request system.The ask, separate from the feature itself: if this repo isn't the right home for Claude.ai requests — and the labels say it isn't — please point to, or stand up, one that is. Anthropic positions Claude.ai as a distinct product from Claude Code; half a dozen identical requests dying in the Code tracker is a strong signal it deserves its own place to receive them.
Commenting to hold off the 3-day auto-close, since right now this is the only one of these still open. Cheers and thanks.
Running into this directly. My setup: one core product with a structured, multi-step pipeline that I run across several distinct client engagements, plus a couple of adjacent products under the same practice.
Current options are both bad:
One flat Project — every client's threads pile into the same list, no way to isolate one campaign's context from another.
Separate Projects per client — isolation, but I lose the shared knowledge base (pipeline instructions, prompt architecture, SOPs) that all of them depend on. I end up duplicating that knowledge base into every project or maintaining it externally and pasting it in each time.
What's described in this issue is what I actually need: one Project per product/practice area, subfolders per client/campaign underneath, Project-level knowledge base and instructions inherited by all subfolders. Naming conventions (Product — ClientName) are the workaround today and they stop scaling past a handful of engagements — both search and the flat list degrade.
The prior art point in the issue is right — nested folders are a 40+ year old solved UX pattern. For a product at this scale, this is a significant gap for anyone running client-based or multi-workstream work through Projects.
I'm literally begging for this feature!
yes sub group(s) or folder under project folder is a must
"subfolders a olved problem for 45 years" xdddddd lol
This feature is essential; I don't need to jump to NotebookLLM to keep the citations of the needed files to check. Hopping from one platform to another.
I work with a small web dev/hosting/marketing agency with nearly 60 small business and nonprofit clients, and the current setup forces a tradeoff I don't think should have to exist.
Right now everything lives in one big "client work" Project, because splitting into a Project per client would mean losing the cross-client knowledge base that's actually the most valuable part of how I use Claude. A lot of what I do is troubleshooting. I'll solve something for Client A (say, a weird WordPress/Elementor conflict, or a CRM automation quirk), and months later Client B hits the same issue. I need that "how we fixed it last time" knowledge to live somewhere Claude can pull from regardless of which client I'm currently working on.
But I also need to get more granular than that master project allows. Different clients (and even different projects within a client) have different dos/don'ts, brand voice, technical constraints, etc. Right now, with everything flattened into one Project, Claude sometimes gets tone wrong or assumes I'm talking about the client I mentioned three chats ago...even when I've just told it which client I am working on. Sub-folders with their own instructions/knowledge would fix that.
A couple of specific things that would matter for my use case:
Multiple nesting levels would help: I have a few clients with multiple distinct brands under them, but even a single nested level would be a huge improvement over what exists today.
The first nested layer needs full Project-level functionality: Its own knowledge base, its own instructions, not a stripped-down version. That's where the actual client-specific work happens. I'd be fine with deeper levels being more limited if that's what it takes to ship this.
I desperately need one shared master layer for cross-client knowledge and at least one fully-functional nested layer per client/brand for the specifics. This feature would make this dramatically more usable for anyone managing multiple clients or projects under one umbrella.
reply<<
I agree similar to you I created multiple projects for multiple companies, uses common skills and specific skills. what I would suggest you to create a eg. Hub Skill - to update and sync skills across multiple projects. I scheduled and and make copies of skills and memories as a back up on claude docs. I ask to check update and sync skills across projects. I saved lots of time and token. still sub folder structure is essential. this holds for groups, projects, pinned items and claude docs ( no folder all docs are listed now , amazingly >>
I found a great way to solve this I asked Claude to create an Artifact hub. make sure it add links to conversations and code as well it will help a lot until antropic comes up with an update hope it helps
<img width="1890" height="862" alt="Image" src="https://github.com/user-attachments/assets/a8f36bca-4619-4424-86b5-4291eb384b6b" />
Use case: student advising in higher education
I am a university faculty member in a pharmacy program in Japan, and I use Claude to support student advising (e.g., study guidance, exam preparation, academic consultations). This work has a clear two-level structure:
Problem with the current design
Projects are flat, which forces a trade-off:
Workarounds such as naming conventions ("[4th year] ...") only change how chats are sorted; they do not provide separate context or instructions.
Proposed behavior
Relation to Claude Code
I also intend to automate parts of this workflow with Claude Code (e.g., preparing advising materials and organizing records in a local folder structured by cohort). Claude Code already supports exactly the inheritance model requested here: CLAUDE.md files in parent directories are combined with those in subdirectories, so shared guidance lives at the top and cohort-specific guidance lives below it.
It would be very helpful if Claude.ai Projects followed the same model, so that the same structure works consistently across both surfaces:
Why this matters for education
Student advising involves sensitive personal information. Clear separation between units, combined with consistent shared guidance, makes it easier to use Claude responsibly in this setting. The same structure would benefit other fields with a "shared policy + many separate cases" pattern, such as clinical teaching, counseling, legal work, and client services.