Native Integration Between ChatGPT Projects and Codex

ChatGPT Feature requests
, ,
1

Feature Request: Native Integration Between ChatGPT Projects and Codex

Problem

Many users perform their product thinking, research, planning, UX decisions, technical specifications, and business discussions inside a ChatGPT Project.

They then move to Codex to implement the product.

Today, these two workflows are not fully connected. Users must manually transfer context, copy specifications, update documentation, and repeatedly explain their intentions to Codex.

This can lead to:

  • loss of important product context;
  • inconsistencies between the original idea and the implementation;
  • repeated prompts and duplicated work;
  • technical decisions that do not fully reflect the user’s intentions;
  • outdated specifications inside the code repository.

Proposed solution

Allow users to connect a ChatGPT Project directly to a Codex project or code repository.

The connected ChatGPT Project would act as the product and strategic context layer, while Codex would remain the specialized implementation agent.

Core features

1. Shared project context

Codex could access selected elements from the connected ChatGPT Project, such as:

  • project instructions;
  • approved conversations;
  • product requirements;
  • UX and design decisions;
  • technical specifications;
  • uploaded documents;
  • roadmaps;
  • business rules;
  • user feedback;
  • architectural decisions.

The user should be able to choose exactly which information Codex can access.

2. “Send to Codex” action

ChatGPT could display a native action such as:

Send directive to Codex

After a product discussion, ChatGPT could automatically convert the decision into a precise Codex task containing:

  • the objective;
  • relevant project context;
  • acceptance criteria;
  • affected files or components;
  • technical constraints;
  • tests to run;
  • documentation to update.

The user would review and approve the directive before execution.

3. Context-aware task generation

Because ChatGPT understands the complete history and intentions of the project, it could create more precise development directives than a standalone coding prompt.

This should make Codex outputs:

  • more aligned with the user’s product vision;
  • more consistent with previous decisions;
  • less dependent on repeated explanations;
  • safer and easier to validate.

4. Bidirectional synchronization

After completing a task, Codex could return a structured report to the ChatGPT Project containing:

  • changes made;
  • files modified;
  • tests performed;
  • unresolved issues;
  • architectural decisions;
  • new technical limitations;
  • recommended next steps.

ChatGPT could then update the product documentation and continue the strategic discussion using the latest implementation state.

5. Shared source of truth

ChatGPT and Codex could maintain synchronized project documents such as:

  • PRODUCT.md;
  • AGENTS.md;
  • ARCHITECTURE.md;
  • ROADMAP.md;
  • DECISIONS.md;
  • DESIGN_SYSTEM.md;
  • CHANGELOG.md.

Users could decide whether these documents live in the ChatGPT Project, the repository, or both.

6. Permissions and approval controls

The integration should include granular controls:

  • select which chats and files are shared;
  • read-only or editable access;
  • approval before sending a task;
  • approval before modifying important files;
  • visibility into the exact context provided to Codex;
  • ability to disconnect the projects at any time.

Example workflow

  1. A user discusses a new feature inside their ChatGPT Project.
  2. ChatGPT analyzes the existing product vision, UX rules, architecture, and previous decisions.
  3. ChatGPT proposes a complete implementation directive.
  4. The user clicks “Send to Codex”.
  5. Codex modifies the repository, runs the tests, and prepares a summary.
  6. The result is returned to the original ChatGPT Project.
  7. ChatGPT updates the roadmap, documentation, and recommended next steps.

Example use case

A user building a health application discusses a new coach dashboard inside ChatGPT.

The project already contains information about:

  • the target users;
  • privacy requirements;
  • health-data restrictions;
  • the design system;
  • the existing mobile experience;
  • the backend architecture;
  • the expected coach and athlete workflows.

ChatGPT converts all this context into a precise Codex directive. Codex can therefore implement the feature without the user manually rewriting the full context.

Benefits

This integration would:

  • connect product thinking directly to implementation;
  • reduce context loss;
  • improve the quality of Codex outputs;
  • make ChatGPT Projects more useful for long-term software development;
  • reduce repetitive prompting;
  • improve consistency across product, design, and engineering;
  • create a more complete end-to-end development workflow inside OpenAI products.

Suggested product concept

ChatGPT Project = product brain and source of intent

Codex = specialized engineering and execution layer

Connecting the two would allow users to move naturally from an idea, to a decision, to an implementation, while preserving the full project context.

2

Thanks for the detailed proposal! Work and Codex share the desktop app for eligible accounts, with rollout and workspace settings affecting access; their history remains distinct: https://help.openai.com/en/articles/20001275. We'll pass along your request for selective project context, reviewed handoffs and two-way synchronization. No timeline to share.

5

I really like the direction of this proposal — particularly the separation of roles:

ChatGPT Project = knowledge, intent, and decision layer
Codex = execution layer

I think there may be an opportunity to extend this architecture one step further: dynamic context orchestration across OpenAI tools.

The idea would not be limited to passing context from a specific Project to Codex. A broader layer could continuously understand the structure of the user’s knowledge, maintain its current state, and select the most relevant context for a particular task.

For the sake of discussion, this could be called:

DYNAMIC CONTEXT ORCHESTRATOR

  1. A Project does not necessarily need to be selected before a conversation starts

The current model largely follows:

User
→ selects a Project
→ starts a conversation
→ the conversation uses the Project context

It could potentially support the reverse direction as well:

User
→ has a conversation
→ AI analyzes its meaning
→ detects a relationship with an existing Project
→ suggests the appropriate assignment

In analytical work, the real significance of a conversation is not always obvious when it begins.

A discussion that starts around a relatively narrow problem may later lead to broader decisions, dependencies, or architectural conclusions relevant to an entire Project.

A Project could therefore function not only as a source of context, but also as a structure that AI helps continuously enrich and organize based on the actual meaning of the work.

  1. Semantic segmentation instead of a strict “one chat = one project” model

The boundaries between topics do not always match the boundaries between conversations.

During one analytical session, a user may begin with a problem related to Project A, discover a dependency involving Project B, make a decision relevant to both, and then return to the original topic.

This does not necessarily mean that the entire conversation should belong to multiple Projects or be physically split into separate chats.

Instead, the system could create semantic references to specific knowledge units:

Conversation
├── Context unit A → Project A
├── Context unit B → Project B
└── Decision C → Project A + Project B

In this model, the conversation remains the place where knowledge is created, but it does not have to be the only unit used for context management.

A context unit could instead be:

  • a decision,
  • a requirement,
  • a constraint,
  • an assumption,
  • an analytical result,
  • an unresolved question,
  • a dependency.

This could preserve a natural way of working without requiring users to start a new conversation whenever the analytical perspective changes.

  1. Dynamic conversation naming

A conversation title is currently mainly a navigation label generated relatively early in the conversation lifecycle.

However, the real function of a conversation may only become clear later.

A conversation may begin as:

“Integration issue”

but eventually become primarily about:

“Architecture for cross-system context synchronization”

AI could periodically suggest a more precise title based on the actual current content of the conversation.

The original title could remain available in history.

This would make the title a form of dynamic metadata describing the conversation’s current role within the broader knowledge structure rather than a one-time label.

  1. Automatically maintained metadata layer

Beyond the title itself, AI could also maintain additional metadata for conversations and extracted context units, such as:

  • Project,
  • topic,
  • related Projects,
  • related conversations,
  • decisions,
  • requirements,
  • constraints,
  • unresolved questions,
  • related files,
  • related tasks,
  • current / historical / superseded status.

The goal would therefore go beyond improving search.

It would create a semantic organizational layer above the user’s conversation history.

In this model, a conversation would no longer be only a text document.

It would become part of a broader knowledge structure with meaning, relationships, and state.

  1. Dynamic Context Orchestrator between ChatGPT and Codex

This seems to be the most important part of such an extension.

I am not convinced that automatically sending the entire Project history to Codex would always be the best solution.

More context does not necessarily mean better context.

What matters more is:

  • relevance,
  • freshness,
  • information priority,
  • low redundancy,
  • and distinguishing current knowledge from historical knowledge.

Before a task is executed, there could therefore be a retrieval layer:

Task
↓
Dynamic Context Orchestrator
↓
semantic retrieval
↓
relevance filtering
↓
current-state verification
↓
context compression / selection
↓
Context Package
↓
Codex

For example, for a particular task the system might identify:

Architecture decision
→ very high relevance

Current requirement
→ very high relevance

Previously rejected solution
→ relevant as a constraint

Historical brainstorming
→ low relevance

Unrelated discussion
→ excluded

Codex would then receive a task-specific operational context package rather than the entire Project history.

The model would therefore look more like:

Project knowledge
+
conversation knowledge
+
current decisions
+
task intent
↓
dynamic retrieval
↓
task-specific context package
↓
Codex

  1. Context Graph rather than only a Project hierarchy

Projects are a very useful organizational layer for humans.

However, project knowledge rarely forms a pure tree structure.

One decision may affect several areas.

One requirement may be relevant to several tools.

One part of a conversation may matter to multiple future tasks.

Underneath the visible Project structure, there could therefore be a semantic relationship layer:

Conversation
↔ Context unit
↔ Project
↔ Decision
↔ Requirement
↔ File
↔ Task
↔ Codex execution
↔ Result

Projects could remain the simple and understandable organizational layer for the user, while AI maintains a more flexible Context Graph underneath.

The user would not need to construct that graph manually.

It could emerge naturally from normal work.

  1. Context as state, not only as an archive

This distinction seems particularly important.

A Project may contain:

Decision A
→ earlier decision

Decision B
→ later replaced Decision A

Decision A remains part of the Project history, but it should not be treated by a future agent as a current instruction.

The context layer should therefore understand not only:

“What was previously discussed?”

but also:

“What is currently valid?”

Possible states could include:

CURRENT
SUPERSEDED
REJECTED
HISTORICAL
UNRESOLVED
EXPERIMENTAL

This would turn Project context into a dynamic knowledge state rather than an ever-growing archive.

  1. Reorganization of existing conversation history

The same logic could also work retrospectively.

A user could trigger an operation such as:

Analyze my workspace

AI could then propose:

Current title
→ Suggested semantic title

Conversation
→ Suggested Project

Context units
→ Related Projects

Related conversations
→ X, Y, Z

Potential duplicates
→ detected

Superseded decisions
→ detected

Unresolved topics
→ detected

The proposed changes could then be reviewed and approved by the user.

This could provide a way to transform years of ChatGPT history from a chronological list of conversations into a more structured knowledge environment without requiring users to manually reorganize large numbers of chats.

  1. Different automation levels

I would not see this as mandatory automation.

Users should be able to decide how much organizational control they want to delegate to AI.

For example:

MANUAL
AI only suggests changes.

ASSISTED
AI automatically performs basic classification, while important changes require approval.

AUTOMATIC
For selected Projects, the user allows AI to continuously maintain context structure and state.

The goal of the Orchestrator would be to reduce organizational overhead while keeping the user in control of their own knowledge environment.

  1. Context security and boundaries

Automatic context routing would also require clearly defined boundaries.

A user could define rules such as:

Project A
→ may use context from Project B

Project B
→ isolated

Private context
→ must never be exposed to Work context

Selected Project
→ Codex access allowed

Selected Project
→ external connector access prohibited

The more intelligent context management becomes, the more important it becomes to control what information may flow between tools.

For that reason, context orchestration and context security seem naturally connected and should probably be designed together.

The target architecture could look roughly like this:

USER
↓
conversations / files / decisions / requirements / tasks
↓
DYNAMIC CONTEXT ORCHESTRATOR
↓
semantic classification
context segmentation
relationship mapping
state management
relevance evaluation
↓
PROJECTS + CONTEXT GRAPH
↓
task-specific retrieval
↓
CONTEXT PACKAGE
↓
CHATGPT / CODEX / WORK / other OpenAI tools
↓
results / decisions / state changes
↓
CONTEXT UPDATE
↓
DYNAMIC CONTEXT ORCHESTRATOR

This is why I see the concept as a natural extension of the idea described in the original post.

The original proposal addresses the following question very well:

“How can ChatGPT Projects and Codex operate on shared context?”

A possible next question could be:

“How can the system itself understand the structure of the user’s knowledge, maintain its current state, and deliver the right context to the right tool at exactly the right moment?”

In that model, a Project would no longer be only a context container.

It would become part of a dynamic knowledge-management system.

ChatGPT could then serve not only as the “product brain,” but also as a layer that helps orchestrate context across Projects, Codex, Work, and future OpenAI tools.

6

This proposal matches a practical workflow we are trying to support: developing requirements and decisions in ChatGPT, then asking Codex to consult the selected conversation while working on a local project.

The difficult part is continuity. Important decisions may be far back in the conversation, assistant responses may be long, and the discussion may continue after the initial handoff. Repeatedly copying text or preparing exports adds work and makes it harder to know whether Codex has the current context.

Our minimum useful integration would be read-only access to explicitly selected conversations, with source references, clear coverage and truncation signals, and a way to retrieve subsequent updates. Bidirectional synchronization would not be necessary for that first step.

For developers already using this workflow:

  1. Which supported approach works in practice: native access, exports, or curated handoff documents?
  2. How do you verify older-history coverage, full response text, and the selected conversation branch?
  3. How do you handle later updates, and what latency, manual effort, or maintenance does that involve?

Concrete examples with platform/version and known limitations would be especially useful. We are discussing native-reader behavior separately in issue #50509; here, I would value practical experience and comparisons rather than another bug-report thread.