{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiakqrw3mejzkucpr56fqtdkc4j2psghnrnyazkrngtakcdqp5gpkq",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mjofepas22k2"
  },
  "path": "/t/feature-request-native-chatgpt-codex-thread-bridge/1379162#post_1",
  "publishedAt": "2026-04-17T07:01:00.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "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"
  ],
  "textContent": "I want to ask the Codex team a direct product question.\n\nCodex 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.\n\nWhat is blocking a first-party bridge here?\n\nI also want to raise a second issue: the feedback path for ChatGPT/Codex product requests still feels too invisible.\n\nCodex 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.\n\nI am not asking for raw transcript mirroring. I am asking for an intentional handoff flow, something like:\n\n- create an explicit handoff capsule from a ChatGPT chat\n\n- store selected context, goals, constraints, and artifacts in that capsule\n\n- start or link a Codex thread from it\n\n- let ChatGPT query status, summaries, and outputs from the same shared object later\n\nThe obvious workaround is to build this ourselves with:\n\n- a local-first broker\n\n- backend-owned durable state\n\n- a ChatGPT-facing MCP endpoint over HTTPS/tunnel\n\n- Codex SDK/app-server control of local Codex threads\n\nThat workaround seems possible, but awkward. Which makes me think the real missing piece is product integration, policy, or prioritization rather than capability.\n\nSo the actual question is:\n\nIs the absence of a native ChatGPT<->Codex bridge an intentional boundary, a security/privacy issue, an architectural issue, or just not yet prioritized?\n\nAnd alongside that:\n\nCan 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?\n\nIf the team is already thinking about this, I would strongly encourage building around explicit handoff objects rather than full chat mirroring.\n\nRelevant docs:\n\n- https://help.openai.com/en/articles/11369540-codex-in-chatgpt\n\n- Managing State – Apps SDK | OpenAI Developers\n\n- SDK – Codex | OpenAI Developers\n\n- App Server – Codex | OpenAI Developers",
  "title": "Feature request: native ChatGPT<->Codex thread bridge"
}