Feature request: native ChatGPT<->Codex thread bridge

Codex
1

I want to ask the Codex team a direct product question.

Codex now shares account-level sign-in and cross-surface positioning with ChatGPT, but there still seems to be no native way to take an ordinary ChatGPT conversation and promote it into a Codex thread with a durable link back to that original discussion.

What is blocking a first-party bridge here?

I also want to raise a second issue: the feedback path for ChatGPT/Codex product requests still feels too invisible.

Codex CLI / the VS Code terminal workflow has a clearer feeling of “there is somewhere to send this.” Ordinary ChatGPT use does not. For users who invest heavily in the product, that creates a recurring frustration that feedback may not be reaching the right team in a visible or durable way.

I am not asking for raw transcript mirroring. I am asking for an intentional handoff flow, something like:

- create an explicit handoff capsule from a ChatGPT chat

- store selected context, goals, constraints, and artifacts in that capsule

- start or link a Codex thread from it

- let ChatGPT query status, summaries, and outputs from the same shared object later

The obvious workaround is to build this ourselves with:

- a local-first broker

- backend-owned durable state

- a ChatGPT-facing MCP endpoint over HTTPS/tunnel

- Codex SDK/app-server control of local Codex threads

That workaround seems possible, but awkward. Which makes me think the real missing piece is product integration, policy, or prioritization rather than capability.

So the actual question is:

Is the absence of a native ChatGPT<->Codex bridge an intentional boundary, a security/privacy issue, an architectural issue, or just not yet prioritized?

And alongside that:

Can OpenAI make product feedback much easier to submit and track from ChatGPT and Codex themselves, with an obvious in-product route and a visible acknowledgement?

If the team is already thinking about this, I would strongly encourage building around explicit handoff objects rather than full chat mirroring.

Relevant docs:

- https://help.openai.com/en/articles/11369540-codex-in-chatgpt

- Managing State – Apps SDK | OpenAI Developers

- SDK – Codex | OpenAI Developers

- App Server – Codex | OpenAI Developers

2

Totally get why this feels like a gap. You’re not the only one asking for a cleaner bridge and a more visible feedback loop.

From what we’ve seen, this isn’t a hard technical blocker as much as a missing product layer. The pieces exist, but the “handoff” experience between ChatGPT and Codex hasn’t been fully stitched together yet. Same story with feedback, it works today, but it’s not obvious or trackable, which makes it feel like it disappears.

Your idea around explicit handoff objects (instead of full chat mirroring) lines up with how a lot of folks are thinking about it. Way more practical and controllable.

I’ve flagged this and shared it with the team for proper logging so it doesn’t get lost. The feedback angle especially comes up a lot, so you’re adding weight to something that’s already on the radar.

-Mark G.

3

Thanks, good to hear back. As far as Im concerned, Pro is streets ahead of every other model. Now that its got so fast, its a crime not to use it. For me, Giving Pro access to Codex or VScode would basically be AGI. The main blockers and errors in my code comes because Pro doesn’t have full state over the repo. Codex (especially not in plan mode) is a clunky thinker and really doesn’t understand subtleties, so it tends to misinterpret fine distinctions or why something is being done. Which means its explanations to Pro are often not quite right, and the cycle goes off the rails.