[Feature]: Auto-import Codex conversations created outside T3 Code

[coygeek]

Summary

Automatically discover Codex threads created outside T3 Code and add them to the matching T3 environment. A conversation started in Codex CLI or another Codex client should appear in T3 Code when the configured provider can access it through the same CODEX_HOME.

Problem to solve

T3 Code only shows the Codex threads it already knows about. If a user starts work in Codex CLI or the Codex experience in ChatGPT for macOS, that conversation is absent from T3 Code even when both clients use the same Codex account, home, and workspace. The user cannot review or continue that work from T3 Code's desktop, web, or mobile clients, so their Codex history is split according to which client created each thread.

Proposed behavior

When a Codex provider connects or starts, T3 Code should discover persisted Codex threads available to that provider and reconcile them with its own thread list. It should repeat this reconciliation while the provider is running so new external threads and turns appear without a manual import action.

• Match an external thread to the Codex provider instance that owns its configured CODEX_HOME.
• Place the thread in the existing T3 project that matches its working directory. If there is no matching project, keep the thread accessible in a clear unassigned state instead of dropping it.
• Preserve the Codex thread identity, transcript, timestamps, status, and source metadata that the provider exposes.
• Treat repeated discovery as an update to the same thread. Never create duplicates for one Codex thread ID.
• Pick up later turns added by another Codex client without duplicating or reordering history.
• Let the user resume an imported conversation. The next turn should continue the original Codex thread rather than create a disconnected copy.
• Run discovery on the T3 environment that owns the provider and its filesystem state. Every connected T3 client should see the reconciled result through the normal environment sync.

The import should not rewrite, move, archive, or otherwise mutate a Codex conversation merely because T3 Code discovered it. The original thread should change only when the user takes an action that normally changes a thread, such as sending a new turn or archiving it.

Acceptance criteria

• Given a Codex thread created outside T3 Code under the configured CODEX_HOME, starting or reconnecting that Codex provider makes the thread visible in T3 Code without a manual export or file copy.
• A thread whose working directory matches an existing T3 project appears under that project. A thread with no matching project remains discoverable in an unassigned state.
• Opening an imported thread shows the user and assistant history exposed by Codex in the original order, with no synthetic duplicate messages.
• Discovering the same Codex thread more than once produces one T3 thread, keyed to the same provider thread identity.
• If another Codex client creates a thread or appends turns while T3 Code remains connected, automatic reconciliation adds or updates the T3 thread and preserves the prior history.
• Sending a message from an imported thread resumes the original Codex conversation. Reopening it from Codex CLI or another compatible Codex client shows that new turn in the same thread.
• Discovery works when the T3 environment is hosted by the desktop app or npx t3, and the imported thread is visible from the web, desktop, and mobile clients connected to that environment.
• Threads created normally inside T3 Code continue to behave as they do today and are not duplicated by reconciliation.
• Missing, unreadable, unsupported, or malformed external thread records do not prevent T3 Code from listing its existing threads. The provider reports enough context to diagnose skipped records without exposing conversation content or machine-local home paths in ordinary client logs.

Affected area

The Codex provider adapter, environment-owned thread discovery and reconciliation, project assignment, and the shared thread list used by the web, desktop, and mobile clients.

Non-goals

• Importing conversations from Claude, Cursor, Grok, OpenCode, or other providers.
• Importing cloud-only ChatGPT conversations that the configured Codex provider does not expose.
• Syncing conversations between different CODEX_HOME directories or T3 environments.
• Inventing a new cross-provider transcript format or promising that every Codex item type can be edited in T3 Code.
• Changing Codex's storage layout or requiring users to copy session files into T3 home.

Alternatives considered

A manual "Import conversation" action would help with one-off migrations, but it would leave users repeating the same step whenever they start or continue a thread elsewhere. Automatic reconciliation better matches the expectation that one Codex home has one visible history.

Reading Codex session files directly would tie T3 Code to private storage details and make compatibility harder across Codex releases. Codex already exposes persisted thread listing, reading, and resuming through its app-server protocol, so the required behavior should be built around supported provider capabilities where possible. The exact adapter and persistence design should remain an implementation choice.

Supporting context

• T3 Code documents Codex as a supported provider and describes a shared CODEX_HOME as a shared Codex session workspace: Codex provider guide.
• Codex app-server exposes thread/list for persisted threads, thread/read for history, and thread/resume for continuing a thread: Codex app-server protocol.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Thanks for the proposal. Automatic discovery and reconciliation of external Codex conversations is tracked in Ideas discussion #6680.

I added the source requirements there before closure. They include project matching, idempotent updates, later turns from other Codex clients, continuation of the original thread, and visibility to every client connected to the owning T3 environment. PR #8054 is an open implementation proposal. It has not merged and is not evidence that this feature is implemented or fixed.

I'm closing this as a feature request tracked in Ideas as part of an automated pass on all open issues. This is a policy move, not a fix confirmation.

[amarcin]

Concrete reproduction of the “later turns from another Codex client” case on the current desktop/mobile setup:

Environment

• T3 Code Alpha 0.0.38
• macOS 26.6.2, arm64
• Codex CLI 0.153.0-alpha.5
• Codex authenticated through Amazon Bedrock
• ChatGPT Codex desktop and T3 use the same local Codex state
• T3 iOS is connected to the desktop-hosted environment

Steps

1. Start or resume a Codex-backed thread in T3 and send a message.
2. Open the same underlying Codex thread in the ChatGPT Codex desktop app.
3. Send a new message from ChatGPT Codex desktop.
4. Return to the thread in T3 desktop and T3 iOS.

Actual result

The ChatGPT Codex desktop transcript contains both the original T3 turn and the externally added turn. T3 continues to show its previously projected transcript and does not add the turn created by ChatGPT Codex desktop. The thread can eventually be discovered/listed, but its history remains stale.

Expected result

When T3 reconnects to or resumes a known Codex thread, it should reconcile provider history into the existing T3 thread, deduplicating by provider thread/turn/item identity and preserving ordering. An externally appended turn should appear on every T3 client connected to the environment.

This is distinct from importing an unrelated cloud ChatGPT chat: it is the same resumable Codex thread identity, continued by another Codex client.

The related writer-conflict reproduction is being added separately to #8259.