Repository navigation
Bi-directionally sync t3.code threads with provider threads #876
Description
Activity
pls change the wording, i thought you where talking about t3chat.
@binbandit is this doable with the current architecture?
- changed the title
[-]Bi-directionally sync T3 chat threads with provider threads[/-][+]Bi-directionally sync t3.code threads with provider threads[/+]on Mar 15, 2026 I was also just looking into this from a codex desktop app, antigravity sense as well, if I need to jump around in tools but prefer to use T3 Code for day to day usage. It would be nice to reference and find those threads / conversations.
hm. after thinking more about this, i'll close for now as not planned, i think the separation between them is ok, they're different apps / experiences
for example you would use codex and open it everywhere on your computer, but you dont want 100 folders you've opened to change one thing to be a thread on t3code.
Possible to revisit this idea? It allows me to use t3 code on my desktop but Codex through my phone when away
Reacted by Muhammad Inshal YousafThis is a serious limitation.
T3 should not decide this workflow on behalf of users. Users should be able to choose whether project-related CLI session histories are shown in T3 and resumed from there. This is directly relevant to the core purpose of the project and should be treated as a proper feature, not an optional edge case.
For example, when a project has six existing sessions built around a 1M context window, abandoning that accumulated session context and starting fresh in T3 is not a practical option.
The reverse case is even more problematic: if a project is started in T3 and the user later needs or wants to move back to the CLI, not being able to resume that work makes the workflow unsustainable.
Is it possible to import project-level threads from Codex into T3Code for someone who's just starting out with T3Code?
Problem
T3 code threads currently sync one way with the source provider.
Desired behavior
Thread state should bi-directionally sync with the source provider so T3 and the provider UI/CLI stay aligned.
Specifically:
Why this matters
Right now T3 can act as a source of threads for Codex CLI, but it cannot reliably reflect work that happens in the CLI afterward. That breaks continuity between the two surfaces and makes T3 an incomplete view of session history and live progress.
Acceptance criteria