ChatGPT ↔ Codex Bridge: A Bidirectional Workflow for Software Architecture and Development

[julianovmartins]

Feature Request: ChatGPT ↔ Codex Bridge

Dear OpenAI Team,

I would like to propose a native integration between regular ChatGPT conversations and Codex, with a simple action to generate a prompt and send it directly to Codex.

How This Differs from ChatGPT Work

I understand that Work already offers ways to coordinate tasks with Codex. This proposal focuses specifically on regular ChatGPT conversations: turning an architectural discussion into a prompt that can be reviewed and sent directly to Codex, then bringing selected results back to the original conversation. The goal is to support this workflow without requiring users to move their discussion into Work, replacing the manual copying and pasting they already do between the two tools.

Usage efficiency is a central reason for this distinction. OpenAI’s documentation states that Work follows the same usage structure as Codex. Users should be able to keep architectural discussions and prompt preparation in regular ChatGPT, under its own usage limits, and reserve their Work/Codex allowance for repository inspection, implementation, and testing. Moving the discussion into Work is therefore not an equivalent solution for users trying to conserve that allowance.

The intended separation is deliberate: use regular ChatGPT to discuss architecture, evaluate alternatives, and decide what should be built; use Codex for hands-on programming, including inspecting the codebase, editing files, running commands, and testing changes. Architectural discussion alone should not require consuming the Work/Codex allowance. A direct bridge would let users reserve that allowance for execution while keeping planning in regular ChatGPT.

The request is not for free Codex execution: actual tasks would remain subject to normal Codex usage rules. It is for a direct handoff that does not require an additional agent run merely to transfer an already prepared prompt or return selected results.

Current Workflow

Today, I work with two screens: one for discussing architecture in ChatGPT and another for executing tasks in Codex. I manually copy prompts from ChatGPT to Codex and bring the results back to ChatGPT to continue the discussion.

This is an existing workflow, not a hypothetical use case. I already do it manually, and other users who combine ChatGPT discussions with Codex execution face the same need to transfer instructions and results. The absence of an integration does not remove that need; it leaves users to handle the handoff themselves.

A native bridge would make this existing workflow easier rather than require users to adopt a new one. Users could keep working this way, with less copying, fewer interruptions, and less risk of leaving out relevant context. The workflow will continue to exist without integration; the opportunity is to support it directly.

Proposed Feature: Create and Send a Prompt

ChatGPT could offer a Create prompt for Codex action that turns the discussion into a focused task. After reviewing and editing the prompt, the user could select Send to Codex.

The handoff would allow the user to:

1. Choose the destination Codex project.
2. Select an existing task or create a new one.
3. Review and edit the prompt and any included context.
4. Submit the task directly to Codex.

Only the selected prompt and context should be transferred, rather than the entire ChatGPT conversation by default. Codex would continue to apply its existing permissions and execution controls.

Example Interface: A Send to Codex Prompt Block

For example, a user could type /sendtocodex or ask ChatGPT to prepare a Codex task. ChatGPT would generate the instructions inside a dedicated Send to Codex block in the regular conversation. This would look like a text block, but with an editable prompt and a built-in Send button.

The block could include:

• Prompt: the instructions prepared from the discussion, available for review and editing.
• Destination: a selector for an available Codex project and an existing or new conversation.
• Remember destination: an optional setting to reuse the selected project and conversation for subsequent handoffs in this ChatGPT conversation.
• Send: a user-initiated action that submits the displayed prompt to the selected Codex conversation.
• Retrieve final response: an optional action to bring only the final response for the submitted Codex task back into the ChatGPT conversation, clearly identifying which task it belongs to.

The destination picker should reuse the Codex destinations and availability already exposed by the application, rather than require a separate connection setup. When ChatGPT and Codex are running in the same desktop application on the same machine, the handoff should feel direct. If a destination is unavailable, the block should show that state instead of silently selecting another destination.

The central request is this actionable prompt block inside regular ChatGPT. Remote execution is not a prerequisite for the feature: the block would simply use whichever supported Codex destination the user selects. /sendtocodex is an illustrative command name, not a reference to an existing command.

Returning Results to ChatGPT

Once Codex finishes the submitted task, the prompt block could offer a Retrieve final response button. Only the latest final response for that submission would be returned, rather than the full conversation, intermediate updates, or tool logs. The user could then discuss the outcome and prepare the next task without copying the response manually.

The outgoing prompt could already specify what Codex should include in that final response, for example: “When finished, summarize the changes, tests run, results, and any remaining issues.” This would make the response useful for the architectural discussion without requiring the integration to collect or summarize the full execution history.

Retrieval could be manual initially. An optional setting could return the final response automatically when the task completes. The exact implementation could be left to the product team; the essential request is a simple way to retrieve the completed task’s final response.

Optionally linking a ChatGPT conversation to a Codex task could make the destination easier to select while keeping their conversation histories separate.

This integration should be available in regular ChatGPT. Drafting and transferring a prompt should remain distinct from executing a task in Codex, with clear usage information.

The goal is simple: let users discuss architecture in ChatGPT, execute tasks in Codex, and move between the two through an integrated workflow instead of manual copying and pasting.

Thank you for considering this proposal.

[awolf30]

I agree with this request, but I would suggest one important addition: Allow all three environments—Chat, Work, and Codex—to access the same project repository with consistent read and write capabilities.

My development workflow relies heavily on all three environments, each serving a distinct purpose. Unfortunately, moving between them currently requires significant manual file management, repeated uploads and downloads, and unnecessary back-and-forth.

My Current Workflow

1. Chat – Brainstorming and Specification Development

I begin in Chat to brainstorm ideas, evaluate approaches, refine requirements, and develop detailed technical specifications. Once ready, I generate a Markdown file, download it, and manually upload it into Work, even though both conversations belong to the same Project.

2. Work – Review, Planning, and Project Management

Work reviews the specification for gaps, inconsistencies, and missing requirements. Any findings typically send me back to Chat for revisions, followed by another round of file transfers.

Once finalized, Work creates implementation plans, task breakdowns, dependencies, spreadsheets, charts, and supporting project documentation.

3. Codex – Technical Validation and Implementation

I then transfer these artifacts into Codex for technical evaluation. Codex may identify additional issues requiring clarification or revisions in Chat or Work, creating yet another round of manual transfers.

Once everything is aligned, Codex executes the implementation plan and develops the required code.

The Problem: Three Environments, One Project, Disconnected Workflows

Although all three environments serve valuable purposes, they currently operate more like independent tools than interconnected capabilities within the same Project.

The biggest challenges are repeated file transfers, version synchronization, duplicated context, fragmented feedback, and unnecessary workflow interruptions.

We spend too much time moving and synchronizing information between environments instead of actually developing the project.

Proposed Solution: One Shared Project Repository

Allow Chat, Work, and Codex to access a common project repository where they can read, create, review, and update files based on their respective responsibilities and permissions.

For the desktop application, this could be a shared local directory or Git repository associated with the Project.

Instead of manually transferring files, a simple handoff instruction would be sufficient:

• Chat → Work: “The specification is ready. Review it and create the implementation plan.”

• Work → Codex: “The implementation plan is complete. Review it for technical feasibility.”

• Codex → Chat/Work: “Several issues require clarification. Review the findings and update the documentation.”

All three would work from the same source of truth, with repository identity verification and appropriate version-control safeguards to prevent conflicts or accidental overwrites.

Web Application: Consistent Google Drive Access

For the web application, the same concept could apply through Google Drive, allowing all three environments to access and manage shared project files without unnecessary file-format restrictions.

For example, I recently had Chat generate both Markdown and DOCX files, but attempts to upload them to Google Drive failed. Creating a native Google Doc worked, but that format is not always ideal for technical specifications or subsequent use by Work and Codex.

Users should not have to change file formats or manually transfer documents simply because the environments have different integration limitations.

Shared Access Does Not Require Autonomous Operation

I recognize that Chat, Work, and Codex do not operate continuously or autonomously, and I am not requesting that functionality.

Each environment can still require an explicit user instruction to begin its next task. The improvement is simply allowing all three to access the same project files without requiring manual transfers or repeated context reconstruction.

Final Thoughts

Chat excels at brainstorming and specification development. Work provides structured planning, analysis, and project management. Codex handles technical validation and implementation.

The missing piece is a consistent, shared source of truth accessible to all three environments.

Connecting them through a common repository would significantly improve the development workflow, reduce repetitive tasks, preserve project consistency, and make the transition from concept to implementation far more efficient.

This would be a substantial improvement for anyone using Chat, Work, and Codex together on the same project.

I also, thank you for your consideration of this proposal.