Feature Request: Synchronization of Codex Threads and Session Context Across Devices

[jorgengk]

Feature Request: Synchronization of Codex Threads and Session Context Across Devices

I frequently work across multiple machines (for example a work computer and a home computer) while using Codex to develop software. Currently, Codex threads and session context appear to be tied to the local environment of the machine where the session was started. As a result, when switching devices, the Codex conversation history, reasoning context, and task progress are not available on the second machine.

This creates unnecessary friction in multi-device workflows. When moving from one machine to another, it is often necessary to recreate the context manually, re-explain the architecture of the project, or restart tasks that were already underway.

A very valuable improvement would be the ability to synchronize Codex sessions across devices associated with the same user account.

Ideally this feature would include:

Synchronization of Codex conversation threads across devices

Preservation of task history and reasoning context

Visibility of active or recent Codex sessions from other machines

The ability to continue an existing Codex session seamlessly on another device

Optional cloud storage of session state tied to the user's account

Even if local file paths or environments differ between machines, retaining the conversational context and high-level task history would significantly improve usability. The repository and environment could then be reloaded locally while still preserving the reasoning history of the session.

For users who frequently switch between machines, this would make Codex feel like a persistent development partner rather than a tool that resets context when changing devices.

Thank you for considering this feature.

[etraut-openai]

Thanks for the suggestion. This is a discussion forum. If you'd like to file a feature request, please use the issue tracker instead. We generally prioritize features based on community upvotes in the issue tracker.

[aniruddhaadak80]

The multi-device workflow you describe is increasingly common, and preserving reasoning context across machines would genuinely improve the development experience. The hard part seems to be balancing cloud persistence with local environment differences, especially when paths and repository layouts vary.

To clarify the requirement, how often do you switch devices during active work? It would also help to know whether selective sync is enough, or if you need every session and recent thread to follow you across every machine automatically.

[Nyrok]

The "recreate context manually" problem when switching devices is partly a session sync problem, but also a prompt structure problem.

When your task context lives as typed blocks, role, context, objective, constraints, rather than embedded in conversation history, you can carry it across devices as a plain file. The session history does not need to follow you. The structured prompt becomes the portable source of truth.

That is how I approach cross-machine continuity with flompt, a visual prompt builder that decomposes prompts into 12 semantic blocks and compiles to Claude-optimized XML. Paste the compiled prompt on any machine, in any tool, and you are back in context. Open-source: github.com/Nyrok/flompt

[Companionh]

Hi, I thought the exact same thing as you did and I've been spending the last week trying to implement a codex session/working environment sync across multiple devices.

The project is currently in experimental alpha but the features for sharing all codex sessions work properly and get updated with each turn.

https://github.com/Companionh/codex-workspace-sync

[hendryyeh]

This resonates — I work across machines too and the context loss when switching devices is painful.

I built a tool called CodeVibe that solves a subset of this: it streams your Codex session to an iOS / Android app so you can see the conversation, tool calls, and approval prompts from another device in real time. You can respond from your phone — send prompts, approve file edits, use voice input.

It doesn't do full desktop-to-desktop session migration, but the "visibility of active sessions from other machines" and "ability to continue interacting from another device" points in your request are exactly what it covers.

https://quantiya.ai/codevibe

[aleksandarperak33-hub]

Cross-device session state is a special case of a more general problem: agent work doesn't have a stable address. Once you solve "persistent URL for an agent's context," cross-device sync falls out for free.

This is what I've been building with TokenRip (tokenrip.com). An agent publishes its state as an asset (tokenrip.com/a/<slug>), the URL lives forever, and the same agent on any device fetches by URL to resume. Works across Codex, Claude Code, Cursor, Gemini CLI — any runtime that can fetch a URL.

The architectural bet we made: don't try to sync session files across devices. Instead, make every session state a named artifact with a canonical URL. Device-to-device sync becomes "paste the URL in the new device."

Would be curious if Codex could expose the session context as a URL-addressable object — it'd make this kind of cross-device UX a one-line integration.

[jayleaton]

This was something that bothered me. I use multiple machines. Mac, Windows and multiple Linux machines. I decided to build this natively into https://KaizenAI.codes so you can get all of your provider chats, not just Codex, on any machine you are logged into.

I also set it up to not auto-import, so you can selectively just download the chats you want at that time from the sidebar within that project.

Everyone will get 1gb free cloud storage with a KaizenAI account and paid tiers will get far more storage and this feature will be released later TODAY!

[rashidrao-pk]

I often start implementing a research project on my desktop and later continue on my laptop. Although I'm signed into the same OpenAI account, I can't resume the same Codex conversation. I have to recreate the project context manually, which is time-consuming and loses architectural decisions already discussed.

[d-jiao]

I fully support this proposal. It will be an incredibly useful feature.

[jsegeren]

I ran into this when replacing my Mac: signing into the same account did not bring over my local working environment. One distinction worth preserving in any solution is conversation history versus the files it points to—uncommitted work, linked Git worktrees and old home-directory paths also need to survive.

For people here doing a one-time Mac-to-Mac move, I built an independent open-source CLI alpha: https://github.com/jsegeren/codex-migrate. It stages selected Codex state, custom skills and workspace folders over SSH, preserves the destination login identity, and requires a verified destination backup before replacement.

Disclosure: I maintain it. This is not continuous sync, does not support Windows, and is not an official OpenAI tool. Broader Codex-version and hardware testing is still needed. Keep an independent backup and the old Mac; inspect the selected scope before applying. It does not resolve the ongoing multi-device feature request, but may help with the narrower new-Mac case.

[d-jiao]

Thank you so much for taking the initiative. I hope to contribute to the project as well.

[jsegeren]

Thank you, @d-jiao — I'd really welcome that. The most useful check right now is whether real Codex-created chats and projects reopen correctly after a move, not just whether the copied files match.

I opened a bounded test request here: jsegeren/codex-migrate#1. It uses a disposable account on each Mac and invented data; macOS/Codex versions and a clear pass/fail report would be very helpful. Please don't post credentials, real conversations or private workspace data.

The CLI is still alpha and the signed Mac app isn't released yet. Thanks for offering to help make it safer.

[g3grau]

I usually mount my home via NFS so that user id, paths etc. remain the same across several machines. I have to clone the conda env or whatever tools I use, but in principle I can continue a session seamlessly on another device. There are sometimes garbage messages that cleanup of some temporary space failed, but that doesn't seem to be an issue.
There is one issue though. Some database locking mechanism seems to rule out to use codex on one machine if it already runs somewhere else (including VS code). It would be great if the locking would be able to handle concurrent access from different machines just as it currently can handle multiple sessions on the same machine. Then a lab machine can continue it's job with HW access while I could sit elsewhere and work on another topic. For now VNC is my friend...

[ooocooc]

There is a storage boundary worth checking before treating this as a missing cross-machine locking feature. The Codex source inspected here opens its runtime SQLite databases in WAL mode. SQLite's WAL documentation requires participating processes to be on the same host; WAL does not support this kind of multi-host network-filesystem access. Same-machine concurrency therefore does not establish that sharing the database via NFS is safe.

That does not identify your particular lock error: your installed version and the failing path matter, and it could instead be a separate process/daemon lock. A sanitized error, Codex/extension versions, and whether the affected state path is local or NFS-backed would help distinguish those cases. Please omit credentials and session contents.

Codex documents CODEX_SQLITE_HOME, with sqlite_home config taking precedence, for choosing the SQLite location. That can help isolate the storage question in a fresh, disposable local-state test, not a migration of existing state; it does not establish safe sharing of the rest of CODEX_HOME or provide session synchronization. I would not remove locks or SQLite -wal/-shm files to force concurrent access.

[g3grau]

Thanks for the insight! I have no clue about sqlite, but from the cited paragraph it sounds like WAL is a high-throughput concurrent R/W optimized mode, and I assume that codex even with parallel sessions is only handling a few transactions per second at best? So maybe beside CODEX_SQLITE_HOME it would be possible to define a switch CODEX_SQLITE_WAL_DISABLE and then open the database with another locking mechanism?
However if I read The Database File correctly, this would not be possible because it requires a difference to the database file itself? Sounds weird to me. I hope it is just a process-lifetime log file that differs.

[ooocooc]

The header difference does not make switching impossible. SQLite's file-format specification records rollback versus WAL mode in header bytes 18 and 19. Its compatibility section explicitly describes switching back with journal_mode=DELETE, which restores those version bytes. That is an explanation of SQLite's capability, not a recommendation to change a live Codex database.

It is also not merely a process-lifetime log: WAL mode persists across reopening, and the WAL file can contain committed state. Removing the sidecar is not a mode switch.

For the proposed flag, there are two separate implementation questions:

• The Codex connection path inspected here explicitly requests SqliteJournalMode::Wal when opening a writable pool. A one-off external conversion would not override that startup policy. I have not verified a supported CODEX_SQLITE_WAL_DISABLE option; the documented CODEX_SQLITE_HOME changes the location, not the journal policy.
• Rollback mode can mitigate network-filesystem problems, but it is not a blanket NFS-safety guarantee. SQLite's network-filesystem guidance still calls out locking and sync reliability, and rollback mode permits multiple readers or one writer, not simultaneous readers and a writer. Low transaction volume does not remove those correctness requirements.

So a configurable journal policy is possible in principle, but would need coordinated startup/recovery behavior and testing against the actual filesystem setup. I would not treat a manual mode change as a supported Codex workaround. Your original error and installed versions would still be needed to establish whether that particular blocker is SQLite or a different lock.

[d-jiao]

Same gap here. Native account-level sync is still what we want; until then I forked the Claude Code sync idea into a Codex-specific CLI:

https://github.com/d-jiao/codex-sync

It syncs the local ~/.codex files (sessions, thread names, history, optionally config / rules / skills / memories) to a bucket you control. Files are gzip’d and age-encrypted on the machine before upload (R2 / S3 / GCS / S3-compatible / WebDAV). Thread names and prompt history are merged rather than overwritten; first pull offers a backup.

Not affiliated with OpenAI. Early (v0.x), macOS-only, build from source. Keep both machines on the same Codex version. The ChatGPT desktop app does not pick up pulled threads by itself — quit the app and run codex-sync pull --desktop.

Different from the .codexbundle handoff tool already mentioned in this thread: this one is ongoing encrypted sync, not a one-shot export/import.

Happy to take issues if something breaks. Official sync would still be better.

[liubrain39]

Two workflows in this request are worth separating when evaluating a solution:

• Accessing the original execution from a different screen. The current official remote-connection documentation describes continuing existing chats on a connected host, including mobile access. That host must remain available.
• Moving execution to a different computer. The same documentation describes Handoff with a matching saved Git project on the destination; it does not support handing a chat into a Codex Cloud environment. This is also different from automatically synchronizing every local installation's history.

For people still affected here, which part is missing in your workflow: finding the original conversation, bringing the uncommitted project state with it, or resuming on a new execution host after the old one goes offline? Those distinctions make reports and possible solutions easier to compare.

Disclosure: I am developing CodexAnywhere, an independent concept exploring this continuity problem. The linked guide separates remote access, cloud tasks and moving execution. The site has an email signup for updates; the product does not currently implement session sync or conversation import, and it is not affiliated with OpenAI.