Hierarchical Folders and Context-Aware Organization Within ChatGPT Projects

ChatGPT Feature requests
1

I saw the existing request for nested Projects and folder organization and wanted to add another perspective rather than simply repeat that request.

As Projects grow, the current flat structure of Project → chats/files becomes increasingly difficult to manage. I would love to see true hierarchical organization within a Project, such as:

Project
→ Research
→ Competitors
→ Company A
→ Chats and files

and:

Project
→ Development
→ Feature A
→ Testing
→ Chats and files

Ideally, folders could be nested to whatever depth is useful, or at least several levels deep.

But I think there is an opportunity here to go beyond folders as simply a visual organization feature.

Make the hierarchy meaningful to ChatGPT

It would be extremely useful if folders could also establish context.

For example, if I am working inside:

Project → Research → Competitors → Company A

ChatGPT could understand that the chats and files within that branch are particularly relevant to what I am currently working on.

Moving back up to:

Project → Research

could broaden the available context again.

This could give users a natural way to organize not only what they see, but also help communicate to ChatGPT which subset of a large Project is relevant to the current task.

Why this matters

A Project with five or ten chats is manageable as a flat list. A long-running Project containing dozens or hundreds of conversations, files, research threads, drafts, decisions, and reference materials is not.

Search helps when you already know what you’re looking for, but it doesn’t replace information architecture.

A hierarchical structure could make Projects much more scalable:

Project → Folder → Subfolder → Subfolder → Chats / Files

Combined with context awareness, this could turn Projects from containers of related conversations into genuine long-term workspaces.

I’d especially like to see:

  • Multiple levels of nested folders

  • Chats and files movable between folders

  • Collapsible folder trees

  • Drag-and-drop organization

  • Folder-level context or scope

  • The ability to work at different levels of the hierarchy

I realize some of these ideas go beyond the original nested-folder request, but I think the organizational structure and the context system could complement each other very well.

2

I’d strongly support this, especially if the hierarchy is meaningful to ChatGPT rather than just visual organization.

My main use case is long-running technical projects with many distinct workstreams. I want to start new chats at natural task boundaries, but a large Project eventually becomes a flat collection of many heterogeneous conversations.

A subproject could act as a context boundary:

Project → Subproject → Chat

The Project would retain broad goals, instructions, terminology, and shared files, while the Subproject would contain a smaller, semantically coherent set of chats and intermediate decisions.

That would give ChatGPT a more relevant local context to retrieve from without having to contend with every conversation in the broader Project, while still preserving access to higher-level Project context when needed.

For me, this would be as much a context-management feature as an organizational one.

3

This is very close to something I ran into with longer research projects.

Once a Project accumulated multiple workstreams, the flat chat list became difficult to use even when all the relevant information was technically still there.

I also found that there were really two slightly different needs: keeping a local workstream focused, and keeping some project-wide state that all of the workstreams should still share.

So a Subproject as a context boundary makes a lot of sense to me.

How are you handling that today? Do you mostly rely on separate chats and shared Project files, or do you maintain any kind of project-level / workstream-level handoff or state outside the conversations?

4

I mostly use shared Project files for durable project-wide context and separate chats for individual tasks/workstreams. If the project itself evolves in a way that needs to persist across chats, I’ll usually capture that in a state/checkpoint document.

I treat conversations as relatively isolated by default rather than expecting every chat to draw indiscriminately from everything else in the Project. When another conversation contains something relevant, I’ll explicitly ask ChatGPT to refer back to it.

The exception is when a conversation has accumulated useful procedural history e.g. troubleshooting, decisions, failed approaches, established workflows, etc. In those cases I’ll often keep the thread going because starting fresh can lose useful context.

So I’m effectively managing the hierarchy manually: Project files hold global state, chats hold local workstream state, and I explicitly bridge between them when necessary.

5

I used to work pretty much the same way. The part that eventually became annoying for me was manually copying important changes back into the shared project state.

So I worked out a different setup with ChatGPT. Now I keep the durable project state in a Git repo, and the chats can update those state files there directly instead of me moving things back and forth manually.

We also agreed that most routine state maintenance can happen without bothering me, but when something important is about to become part of the durable project state, that’s where I want the human decision to come in.