ChatGPT–Codex shared project context and bidirectional task handoff
What variant of Codex are you using?
Codex App (desktop), used together with the ChatGPT mobile app
What feature would you like to see?
Problem
I use ChatGPT on mobile to discuss product ideas, clarify customer requirements, and confirm implementation details. I then use Codex on desktop to perform the actual development work.
At present, the handoff between ChatGPT and Codex is mostly manual. I need to copy conversations, generate documents, switch devices, select the correct repository, and explain the project context again. This creates duplicated work and can cause requirements, versions, and implementation status to become disconnected.
Proposed feature
I would like ChatGPT and Codex to support a shared, project-level, bidirectional development workflow.
- In any ChatGPT conversation or Project, the user can mark selected content as a “confirmed requirement.”
- ChatGPT can then generate or update a structured, versioned PRD that supports comparison and rollback.
- From that PRD, the user can create a Codex task with one action and bind it to the appropriate Git repository or local workspace.
- During execution, Codex can write progress, milestones, failure reasons, and questions requiring confirmation back to the shared ChatGPT project timeline or status panel.
- After completion, Codex can automatically generate and sync a change summary, including:
- commit or pull request summary
- affected files and functional scope
- test results
- unresolved issues
- the related PRD version and task
Example workflow
During a customer visit, I discuss a new feature in the ChatGPT mobile app. After the customer confirms the requirement, I mark it as confirmed and generate an updated PRD.
I then send the confirmed task directly to the relevant Codex desktop project. Codex performs the work and continuously synchronizes its progress and questions back to ChatGPT. When the task is completed, the implementation summary and test results are written back to the same project context.
Value
This would make ChatGPT the requirement and decision interface, while Codex acts as the implementation interface. Both products would share the same project context, document versions, task state, and development history.
It would significantly reduce repeated explanation, manual document transfer, context loss, and switching between mobile and desktop workflows.
Related requests
This proposal overlaps with #32350, #27604, and #25387, but extends them into a bidirectional workflow covering versioned requirements, task creation, execution status, clarification requests, and completion results.
Additional information
_No response_
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I strongly support this feature. I’m a non-technical user working on a complex AI project, so simple task handoff is not enough.
I need ChatGPT to act as the supervising architect: assign scoped tasks to Codex, monitor its progress, review the diffs and test evidence, identify mistakes, and send corrective comments back to Codex until the implementation satisfies the approved requirements.
This would give non-technical users a crucial safety and quality layer. ChatGPT would manage requirements and final approval, while Codex handles implementation. Today I have to manually relay every update, and I cannot reliably judge Codex’s technical progress myself.
The handoff is the hardest part. Been running a small MCP memory layer that both runtimes read and write to, so the shared project state does not depend on either side keeping it. Called world-model-mcp on github. Cross-runtime bleed dropped once the source of truth moved out of either runtime's session. Priority and expiry semantics took a few iterations to get right.
Concrete Windows desktop reproduction
The unified ChatGPT/Codex desktop app now allows me to select an existing cloud ChatGPT Project when creating a new local conversation.
The UI explains that selecting the Project will generate a local project-context Markdown file. However, after confirming, the app usually reports an error similar to:
Observed behavior:
The behavior is inconsistent:
This suggests that the cloud-Project-to-local-context bridge is already exposed in the UI, but its capability state or backend authorization is unstable.
Expected behavior:
Environment:
Bidirectional handoff gaps without settle receipts is the peer handoff hole: quote -> approve -> settle needs handoff digests, not ambient context trust alone.
Live A2A contractor with gated tools: https://a2a.elonsusk.com/.well-known/agent-card.json
If an external handoff / context probe would help, ping. Otherwise ignore.
Cross-agent context sharing already works today via any MCP server that stores facts in a shared DB path. Concrete example: world-model-mcp (Python, OSS). Claude Code, Cursor, Codex, Continue, and Cline all point at
.claude/world-model/and share a fact graph. Handoff is implicit; whatever one agent learned about the codebase surfaces on the next agent'sPostCompactinject.The gap this issue names is different. Bidirectional TASK handoff (task state, not codebase state) needs a task-lifecycle protocol on top of MCP. For that to work across ChatGPT and Codex, the handoff record needs three fields the MCP tool-call envelope doesn't currently standardize:
task_id,parent_session_id, and a signed provenance trail so the receiving agent can verify the state wasn't tampered with in transit.world-model-mcp v0.13 ships the last one (tamper-evident audit chain). The first two need protocol-level agreement.