Existing local Codex projects lack a bridge to ChatGPT Projects with Chat + Work while preserving local folders

Summary

This issue is specifically about pre-existing local projects created from folders through Codex / the earlier desktop project system, not newly created account-backed ChatGPT/Web Projects.

The unified ChatGPT desktop app now exposes two materially different project models:

1. Existing/local Codex projects based on folders already on the computer and previously created/recognized through Codex. In my observed setup, these are persisted/recognized through the local Codex state under .codex and continue to be discovered from the machine. These projects can use Work with their local folders, but Chat still reports that local projects do not support Chat.
2. New ChatGPT/Web Projects created through the newer Web Project / ChatGPT Project flow. These can contain both ordinary Chat and Work conversations, but they are account-scoped rather than machine-local in the same way.

Creating a new Web/ChatGPT Project therefore does not solve the original problem for existing local Codex projects. It changes the persistence/discovery model instead of upgrading the existing local project.

Clarified current scope

The original issue was filed when the practical limitation was that a local project could use Work with its local folder, but could not use Chat/Pro models in that same project context. That remains true for existing local Codex projects.

However, newer ChatGPT/Web Projects now support both Chat and Work. The remaining gap is therefore more specific:

• existing local Codex projects retain local-folder/machine discovery behavior, but do not gain the newer Chat + Work project behavior;
• new ChatGPT/Web Projects gain Chat + Work, but are account-backed/account-scoped and do not automatically replace or populate the pre-existing local project when using another ChatGPT account on the same computer.

Observed difference between the two project types

| Behavior | Existing/local Codex project | New ChatGPT/Web Project |
| --- | --- | --- |
| Based on local folders already on the computer | Yes | Not equivalent by default |
| Existing Codex/local project identity preserved | Yes | No; this is a separate project type |
| Automatically recognized from the machine in my observed setup even when switching ChatGPT accounts | Yes | No; it is account-scoped |
| Work can use project context | Yes | Yes |
| Ordinary Chat can live in the same project | No; app reports local projects do not support Chat | Yes |
| Preserves the original local-project/folder model while adding Chat | No | No |

The account distinction matters. If I sign into another ChatGPT account of mine on the same computer, the older/local Codex projects can still be recognized from the machine, while a newly created ChatGPT/Web Project does not automatically populate for that other account.

That means a Web Project is not an equivalent migration path for an existing local Codex project.

Why this matters for Pro subscribers

Many Pro subscribers use Chat/Pro models for high-quality reasoning and review, while also relying on existing local Codex projects for local files, Work history, and established project organization.

For an existing local project, the current product still forces a choice between:

• Chat/Pro reasoning without the existing local-project folder/context; or
• local-folder Work access without the Chat/Pro surface in that same project.

Creating a separate ChatGPT/Web Project can provide Chat + Work, but it does not preserve the same local-project identity or machine-local discovery behavior.

Multi-folder local projects do not bridge the gap

The multi-folder local-project functionality improves how existing local work is organized. A local project can attach related folders and select a primary folder for new Work chats, Git operations, and project-instruction discovery.

That is useful, but it does not turn the existing local project into the newer ChatGPT Project model. Chat still cannot operate directly inside that local project.

Steps to reproduce on macOS

Existing/local Codex project

1. Open a project that was previously created/recognized from a local folder through Codex / the earlier desktop project system.
2. Optionally add more local folders and make one primary.
3. Start from that local project.
4. Switch to Chat or select a Chat/Pro model.
5. Observe the message that local projects do not support Chat.
6. Select Continue as task and observe that the session becomes a Work task instead of remaining a Chat conversation.

New ChatGPT/Web Project control

1. Create a new project using the Web Project / ChatGPT Project option.
2. Observe that both Chat and Work can be used inside that project.
3. Sign into another ChatGPT account on the same computer.
4. Observe that the new ChatGPT/Web Project is not automatically populated there in the same way the pre-existing local Codex projects are recognized from the machine.

Expected behavior

There should be a coherent bridge or migration path for existing local Codex projects so they can gain the newer Chat + Work behavior without losing their local-folder identity, existing project organization, or machine-local discovery characteristics.

Acceptable directions could include:

• upgrade/migrate an existing local Codex project into the newer project model while preserving its attached local folders and existing chats; or
• allow a local project to contain both Chat and Work directly, with explicit user control over which local files or project context Chat can access.

Creating a separate account-scoped Web Project is not an equivalent workaround because it creates a different project identity and persistence/discovery model.

Environment

• macOS unified ChatGPT desktop app
• Existing projects originally created/recognized from local folders through Codex
• Newer multi-folder local project functionality
• New ChatGPT/Web Project flow
• ChatGPT Pro

Secondary model-availability point

The availability of strong Chat-only models such as 5.6-sol-pro makes the gap more visible, because users may want that reasoning surface while reviewing work already organized in an existing local Codex project. But the core issue is broader than one model: it is the lack of project-type parity/migration between the legacy/local Codex project model and the newer account-backed ChatGPT Project model.