[FEATURE] Subfolders / nested organization within a Claude.ai Project (web, desktop, mobile)

Status Open
Maintainer reply None cached
Activity 3 comments · opened Jun 13, 2026

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

  1. I run one Project for a multi-workstream effort with several parallel threads (e.g. planning, research, drafting, review).
  2. Today every chat lands in one flat list inside the Project, so finding the right one means scrolling and guessing.
  3. With subfolders I would group them (e.g. "Planning", "Research", "Drafts"), each thread findable at a glance.
  4. 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).

View original on GitHub ↗

3 Comments

github-actions[bot] · 2 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/36866
  2. https://github.com/anthropics/claude-code/issues/63710

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

ovm512 · 2 months ago

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 /bug and 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.

vincentljpearson-lus · 2 months ago

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.