›_ Codex Issues
Codex Issues / #36304

Feature request: sync local Codex CLI conversations with the matching Codex App project

Open 💬 3 comments Opened Jul 31, 2026 by Taqi20
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

App and CLI (local repositories on macOS)

What feature would you like to see?

I would like optional cross-surface conversation continuity between the Codex desktop app and Codex CLI.

My workflow:

  • I use the Codex desktop app to organize local projects, plan work, retain project context, and review changes.
  • I use Codex CLI in the same local repository for terminal-based implementation.

Requested behavior:
When a Codex CLI session is started from a repository that matches a local Codex App project, make that CLI conversation discoverable from the matching project in the desktop app.

Desired capabilities:

  • Show CLI tasks in the matching local project
  • Open the CLI transcript from the desktop app
  • Continue or hand off the task between CLI and desktop app
  • Clearly label each task as App, CLI, or Cloud
  • Show the associated repository path and Git branch
  • Allow users to opt out of cross-surface visibility

Why this matters:
Without this, project decisions and implementation history are split between surfaces. I must manually copy summaries, context, and decisions between the app and CLI, which increases duplicated context, token usage, and the chance of implementation mistakes.

This would make it practical to use the desktop app for project organization and planning, then switch to CLI for terminal execution without losing the reasoning trail.

Additional information

This request is specifically about the official Codex App and official Codex CLI working on the same local repository. I am not requesting synchronization of third-party editor chats, such as Zed.

Feedback ID: 019fa2c5-db26-7cc0-9c07-a6e50ae76838
Codex CLI version: 0.146.0
Platform: macOS on Apple Silicon (arm64)

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 28 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35679

Powered by Codex Action

Taqi20 · 28 days ago

After reviewing #35679 and the more directly related #21079 and #21974, I think this request can be treated as a narrower local-first slice of the broader multi-endpoint proposal.

The public app-server/thread-store interfaces already appear to provide much of the required data:

  • thread/list supports sourceKinds and exact cwd filtering.
  • A Thread already exposes source, cwd, gitInfo, status, and the thread ID.
  • The app-server already supports thread/read and thread/resume.
  • The thread store treats local JSONL as canonical history and SQLite as queryable metadata.

Possible staged approach

  1. Project-scoped discovery

In the desktop App, query thread/list for the local project's canonical cwd and include CLI sources. Display those results in the matching project using the existing thread ID rather than copying transcripts into a second store.

  1. Read-only continuity first

Open a discovered CLI thread through thread/read. This gives useful transcript continuity without immediately introducing cross-process mutation risks.

  1. Live refresh

Refresh/invalidate App state when the local thread metadata/history changes, or use bounded polling as an initial fallback. This overlaps directly with #21974.

  1. Safe handoff

Add App-to-CLI continuation through thread/resume, but require explicit ownership/handoff or a per-thread lease so two clients cannot start turns on the same thread concurrently.

  1. Workspace identity

Start with exact canonical cwd matching. Then handle symlinks, moved repositories, and multiple worktrees using gitInfo plus path identity, without merging unrelated worktrees accidentally.

Suggested MVP acceptance criteria

  • A CLI-created thread appears under the App project with the same canonical cwd.
  • The App labels its origin as CLI and shows branch/repository metadata when available.
  • Opening it reads the same thread history; no transcript duplication occurs.
  • Unrelated repositories and different CODEX_HOME values are not mixed.
  • Concurrent resume is rejected or requires an explicit handoff.
  • Cross-surface discovery can be disabled.

Would maintainers prefer that this issue be consolidated into #21079/#21974, with the project-matching and handoff criteria added there, or kept as a local-project tracking issue? If this direction aligns with the intended architecture, I can next provide a more source-specific implementation/test outline before discussing whether an invited PR would be useful.

Taqi20 · 28 days ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Allow the new ChatGPT Desktop App to attach to multiple existing Codex CLI and VS Code extension instances #35679 _Powered by Codex Action_

yes somewhat similar, but im asking the project level organization of chats throughout cloud, cli and app