The unified ChatGPT app needs shared project state between Work and Codex

Codex
1

I think the new unified ChatGPT app exposes an important architectural gap between Work and Codex.

The problem is not that Work and Codex have different capabilities. Specialization makes sense.

The problem is that the user is effectively asked to manage the boundary between them.

My real-world use case is a medical review manuscript managed as a repository-driven project. The project has a structured phase system, audit artifacts, validation scripts, Git history, commits, and tagged checkpoints.

A typical task may involve:

  1. reviewing journal requirements;

  2. evaluating the scientific and medical narrative;

  3. inspecting multiple manuscript and audit files;

  4. modifying the manuscript;

  5. running consistency or citation audits;

  6. reviewing the Git diff;

  7. discovering a scientific wording problem;

  8. reconsidering the evidence or argument;

  9. revising the manuscript again;

  10. validating and creating a Git checkpoint.

This is one workflow.

It is not a “Work task” followed by a separate “Codex task.”

Research, reasoning, document production, repository operations, validation, and Git are interleaved within the same project trajectory.

In the current product model, switching between Work and Codex appears to create a context and state boundary. I cannot simply assume that Work has inherited the active Codex task state—including the current phase, previous decisions, rejected alternatives, constraints, and execution history—and vice versa.

As a result, the user has to reconstruct context or build a manual handoff protocol.

I think this is the wrong abstraction layer.

The user should manage a project and its objective, not decide which internal agent should own each step.

A project should own a shared structured state:

  • current objective and milestone;

  • completed work;

  • important decisions and rationale;

  • rejected alternatives;

  • active constraints;

  • unresolved issues;

  • execution and validation history.

Work and Codex should operate on that same project state.

The ideal architecture, in my view, is:

Project owns state. Agents perform work. Capabilities are tools.

The user stays inside the project and states the goal. ChatGPT dynamically uses research, connected apps, document, repository, terminal, Git, and review capabilities as required.

Advanced users could still explicitly choose a Work-focused or Codex-focused mode when needed, but the default should be an automatic project agent with capability routing.

Switching from Work to Codex should change the execution harness—not fragment the project’s working memory.

This matters especially for professional knowledge-engineering workflows: scientific research, quantitative analysis, technical writing, regulatory work, and other projects where domain reasoning and repository-based execution are tightly coupled.

The new unified app has brought Work and Codex into the same interface. The next step, I believe, is to give them a genuinely shared project-state layer.

2

This describes the architectural issue very well. - the Elephant in the room so to speak..
I would extend it to include Chat as part of the required shared Project state.

Following the latest desktop updates, existing ChatGPT Projects are visible again in the unified application. However, a Work thread inside a Project still cannot reliably use the accumulated context contained in the Project’s other Chat conversations.

The result is that Chat, Work and Codex may appear together within one application—and sometimes within one visible Project—without operating from the same underlying knowledge and state.

For established Projects, prior conversations contain requirements, decisions, terminology, rejected approaches and operating rules. Those are part of the Project’s working state, not incidental history. Project source files alone are not an equivalent replacement.

I think the intended model needs to be:

Project owns state. Chat, Work and Codex operate on that state. Handoffs change the execution capability, not the Project’s identity or working memory.

At present, moving between these surfaces can create separate continuations, duplicate Recents entries and uncertain Project membership. The interface is becoming unified, but the underlying Project context remains fragmented.

It would be helpful if OpenAI could clarify whether a genuinely shared Project-state layer across Chat, Work and Codex is the intended end state.

3

I agree that a shared project-state layer is the right foundation.

I would extend this one step further: ChatGPT Live could act as the persistent interaction layer over that shared state.

Users often discover the real task boundary while speaking. Live could turn an unstructured conversation into the project objective, constraints, open questions, and acceptance criteria, then select or create the appropriate execution context—Chat, Work, Codex, an existing repository, or a connected tool—without asking the user to move context between them manually.

The same parent conversation could remain active while the work runs. The user could add a constraint, change direction, ask for progress, approve an action, pause, or cancel part of the task by voice.

Results, artifacts, and verification would return to the same shared project state. Live would ask the user only when an ambiguity materially changes the outcome or an action crosses a meaningful permission boundary.

This would make “Project owns state. Agents perform work.” usable as an interaction model, not only as an internal architecture.

The user states the desired outcome. ChatGPT chooses the execution harness and remains responsible for returning the completed result.

4

Thanks for laying this out! Chat and Work share project organization, and desktop Voice can help coordinate Work and Codex tasks: https://help.openai.com/en/articles/20001275 and https://help.openai.com/en/articles/20001274. Fully shared state across all three modes goes further, so we’ll pass that feedback along. We don’t have a timeline to share.