Codex Desktop: support nested local projects in the Projects sidebar #33304

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 15, 2026
2. nathanlannan commented on Aug 27, 2026

   

   nathanlannan

   on Aug 27, 2026

   More actions

   This describes the hierarchy I need, with one additional use case: the parent may be an organizational group rather than a directory that physically contains every child project.

   For example:

   Game Boy
   ├── Platformer
   │ ├── Fix collision handling
   │ └── Add save system
   ├── Puzzle Game
   │ ├── Design level format
   │ └── Optimize renderer
   └── RPG
   ├── Add inventory
   └── Implement encounters

   “Game Boy” is the larger area of work, the individual games are independent Codex projects, and their chats remain inside their respective projects.

   Automatic grouping based on directory containment would be helpful, but manual grouping is also important because related repositories may live in separate locations. Ideally:

   • Groups can contain projects or additional groups.
   • Existing projects can be moved into and out of groups.
   • Search and Activity results show the project’s breadcrumb.
   • Groups can be renamed, reordered, collapsed, and expanded.
   • At least one level above projects is supported; deeper nesting would be preferable.

   The hierarchy should be organizational only by default. A parent group should not implicitly combine project instructions, attached folders, permissions, memories, source access, or agent context. Each child project should retain its existing isolation.

   👍React with 👍2Reacted by Ezra and Florian Weber
3. awssman commented on Oct 4, 2026

   

   awssman

   on Oct 4, 2026 – with ChatGPT Codex Connector

   More actions

   I support this request and would like the hierarchy to work for SSH remote projects as well as local projects.

   My workflow uses Codex Desktop on Windows connected to a Linux host through SSH. I need to organize several companies, shared operational areas and products in one navigable tree, with multiple levels of collapsible containers:

   Organization
   └── Operations
       ├── Shared Infrastructure
       │   ├── Servers & Services
       │   └── Accounts & Access
       ├── Company Operations
       │   ├── Company A
       │   │   └── Security Tools
       │   └── Company B
       │       ├── Product A
       │       └── Product B
       ├── Runbooks
       └── Change Records
   

   These should be real sidebar containers or child projects, not just indentation in a Markdown file. The filesystem can already contain this directory structure; the request is to represent and manage the organization inside Codex.

   Requested capabilities:

   • Create folders/containers and child projects at multiple levels, with expand/collapse and breadcrumbs.
   • Support both manually defined logical groups and optional import of a local or SSH folder tree.
   • Move existing projects and chats between containers without duplicating or losing conversations.
   • Keep sidebar grouping separate from execution context: each project/chat must retain its exact host and working directory. Grouping must not broaden permissions or silently change which AGENTS.md applies.
   • Provide an explicit, supported way to attach an existing chat to the intended project and verify that association.
   • Expose supported tools/API operations for agents to create, rename and organize native desktop projects and attach existing chats. Creation should be idempotent and readable back from the desktop project list.
   • Removing a sidebar container should preserve underlying folders, repositories and conversation history unless deletion is separately requested.

   In my current session, project and chat listing and section placement tools are available, but native project creation and reassignment to a different native project are not exposed. Adding filesystem folders or an App Server project record is not sufficient evidence that a native desktop project was created. A supported desktop integration would avoid repeated manual setup and keep remote working context accurate.

   The broader need overlaps with #30986 and #25498. I am adding it here because hierarchical project organization is the central requirement. Exact desktop build was not captured.

   👍React with 👍2Reacted by Ezra and Florian Weber
4. cyberxz2077 commented on Oct 5, 2026

   

   cyberxz2077

   on Oct 5, 2026 – with ChatGPT Codex Connector

   More actions

   Custom sidebar sections have helped my workflow, but they solve categorization rather than project hierarchy.

   I currently use sections such as Projects, Study, Life, Engineering, and Work to organize tasks and projects by area. I pin urgent or currently important items, then unpin them when that priority passes so they return to their normal location.

   What remains difficult is representing a project and its related projects or subprojects. My current workaround is to organize their local repository folders deliberately, so the filesystem carries relationships that the sidebar cannot adequately represent.

   I would like these dimensions to remain distinct:

   • Priority: temporary pinning.
   • Area of work: sidebar sections.
   • Project relationships: a navigable parent/child hierarchy.
   • Storage and execution location: the actual repository path and host.

   The distinction raised above between organizational groups and physical directories matches this need. Directory containment could help suggest a hierarchy, but related projects may live in different locations, and changing their organizational relationship should not require moving repositories.

   The sidebar should provide a clear overview of the work, with project details and resources available when expanded. Each project's working directory, permissions, and instructions should remain unchanged by grouping.

   I have described the broader tag-based organization of conversations and resources separately in #51128, which links back to this request.