ChatGPT–Codex shared project context and bidirectional task handoff

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #32130
• #32350

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:

This project cannot be used for a local task.

Observed behavior:

1. Open a new conversation in the Windows desktop app.
2. Select an existing ChatGPT cloud Project.
3. The UI says that local project-context Markdown will be generated.
4. Confirm the selection.
5. The app reports that the Project cannot run locally.

The behavior is inconsistent:

• Initially it failed.
• After restarting Windows, the Project attachment succeeded once.
• Shortly afterward, the same error returned.

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:

• Selecting a cloud ChatGPT Project should reliably materialize its permitted context as a local Markdown file.
• The app should clearly show where that file was created.
• The user should then be able to bind the task to a chosen local folder or repository.
• If the feature is unavailable for the account, Project type, platform, or rollout group, the UI should explain the exact reason before offering the option.
• The UI should clearly distinguish context import from permission to read or modify local files.

Environment:

• Windows desktop unified ChatGPT / Codex app
• Version: 26.715.52143
• Existing cloud ChatGPT Project
• No API, MCP server, cloud runner, or external automation involved

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's PostCompact inject.

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.

I strongly support this request. I think the longer-term direction could be broader than a one-time ChatGPT-to-Codex handoff:

ChatGPT Projects could become the system of record for a software project, ChatGPT Work could act as the product/engineering lead, and Codex could act as the implementation engineering layer.

In my current workflow, I already use these products in roughly that way:

1. Discuss requirements, constraints, architecture, and acceptance criteria in ChatGPT Work.
2. Turn the agreed scope into an implementation task for Codex.
3. Let Codex inspect the repository, implement the change, and run tests.
4. Manually bring the results back to Work.
5. Compare the implementation against the original requirements.
6. Send corrections back to Codex if needed.

The biggest gap is that steps 4–6 are still largely manual.

A useful progression could be:

Phase 1 — Linked task lifecycle

Allow a Work chat to create a linked Codex task for a selected repository/project and read back:

• task status;
• completion result;
• changed files or diff summary;
• test results;
• commits or pull requests;
• blockers and unresolved questions.

Phase 2 — Bidirectional orchestration

Allow Work to:

• answer clarification questions from Codex;
• send follow-up or corrective instructions;
• compare the implementation with the original acceptance criteria;
• request another implementation/test cycle;
• mark the work accepted when the criteria are satisfied.

Phase 3 — Multi-task project orchestration

Allow one ChatGPT Project / Work context to own and coordinate multiple Codex tasks, for example:

• database changes;
• backend implementation;
• frontend implementation;
• tests;
• review or migration work.

The Project would retain the relationship between requirements, decisions, Codex tasks, implementation results, tests, and PRs without requiring the full transcripts of every Codex task to be copied into the main context.

Longer-term direction

The user would remain the product owner and final decision maker, but the responsibilities could become clearer:

ChatGPT Project: project context, requirements, decisions, task history, artifacts, and status
ChatGPT Work: planning, requirements, architecture, task decomposition, review, and acceptance
Codex: repository investigation, implementation, testing, and technical feedback

I do not think the first implementation needs autonomous project management. Even Phase 1—creating a linked Codex task and reliably reading its status and final result from Work—would already remove a significant amount of manual context transfer.

But having the longer-term model in mind would make each incremental improvement part of a coherent development workflow rather than a collection of separate handoff features.

A useful update to this request: recent Codex Desktop behavior suggests that an initial ChatGPT Project → Codex bridge is already starting to exist.

In current builds, users have reported that creating a new Codex task from an existing ChatGPT Project can materialize project context locally, including project instructions being written into an AGENTS.md-style context file under a local .chatgpt-projects/<project-id>/ mirror.

That is encouraging because it means the first prerequisite for this proposal — carrying project context into Codex execution — appears to be emerging in the product.

However, this still seems to be a one-way context bridge rather than a true linked task lifecycle. In reported cases, project-source synchronization is incomplete, and the created Codex task does not appear to retain a reliable project-level identity/link that ChatGPT Work can later use for orchestration.

So the next important step would be to preserve a first-class Project ↔ Codex task relationship and expose it back to ChatGPT Work/Projects, including:

• stable linked task identity;
• task status and progress;
• blockers / clarification requests;
• final implementation result;
• changed files / diff summary;
• test results;
• commits and pull requests;
• follow-up or corrective instructions from Work back to the same Codex task.

In other words, the product now appears to be moving from project context transfer toward the beginning of the requested workflow. The remaining gap is turning that association into a bidirectional task lifecycle and orchestration model.

A useful update to this request: OpenAI’s official ChatGPT Voice documentation now describes task orchestration across Chat, Work, and Codex in the desktop app. Voice can start separate threads, check existing threads, send follow-up instructions, and bring progress, blockers, and results back to the supervising conversation. One official example is starting a Codex task to run tests and investigate failures.

That suggests the core orchestration primitives discussed here already exist in at least some supported product surfaces. The remaining gap is less about inventing the control plane from scratch and more about productizing it as a first-class, text-based ChatGPT Project / Work workflow.

In particular, I would still like to see:

• a durable Project ↔ Codex task relationship with stable IDs;
• persistent, navigable parent/child task links;
• Project/Work-visible task status, progress, blockers, and final results;
• structured return of diffs, test results, commits, and PRs;
• reliable follow-up/corrective instructions to the same Codex task;
• explicit permission state, provenance, and audit history across handoffs/follow-ups;
• multi-task orchestration from one ChatGPT Project;
• cloud/local lifecycle semantics that keep the ChatGPT Project as the system of record.

So I would now frame the long-term direction as: bring the orchestration lifecycle that is already officially exposed through Voice into a durable, first-class Project/Work task model for text workflows as well.