Make Codex CLI sessions available in Codex desktop history

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

• #21076
• #20959
• #20792
• #20493

Powered by Codex Action

And found this juxtaposition pretty interesting today!

1. Install Codex desktop app
2. Get prompted to import local chats (I assumed… Codex from my CLI usage)
3. Surprise! They were Claude chats
4. Tried to access local Codex CLI chats… blocked

Seems backward. Geared toward switchers instead of an OpenAI existing user expanding my usage from CLI to desktop app.

+1 to this. The broader need is Codex-native session continuity across the main entry points: CLI, Desktop, and VS Code/IDE extension, web/cloud sessions

Sessions should be portable artifacts with stable resume IDs/deep links that work across surfaces. Moving between terminal, Desktop, IDE, optionally web should feel like changing views on the same Codex work, not starting from separate silos, unless the user explicitly chooses isolation

Disclosure: I used Codex to help research and draft this comment. I personally reviewed the linked evidence and approved the comment before posting.

Adding a source-backed framing here rather than opening another issue, because this looks like one symptom of a broader Codex-native thread-continuity contract.

My read: this should not require one physical global thread store. It should be one logical continuity contract across multiple physical authorities:

• local threads: local Codex home owns durable state
• cloud/web threads: cloud owns durable state
• cross-surface continuity: stable IDs/deep links/fork/delegation provenance connect the two, without pretending the same mutable artifact lives everywhere

What I verified:

• The public docs define a thread as a resumable session and explicitly distinguish local threads from cloud threads: https://developers.openai.com/codex/prompting#threads
• The app docs say that when selecting a project, prior App/CLI/IDE projects should be visible: https://developers.openai.com/codex/app
• App-server already exposes the right local substrate: thread/list, thread/read, thread/resume, thread/fork, and thread/turns/list: https://developers.openai.com/codex/app-server#threads
• In source, local metadata and transcript durability are already separate: SQLite thread rows include rollout_path, source, cwd, timestamps, title, archive state, etc., while rollout JSONL files carry the full persisted session log:
• https://github.com/openai/codex/blob/9d579813bbcafde0abd4010f57ac93eea0b1be2b/codex-rs/state/migrations/0001_threads.sql#L1-L25
• https://github.com/openai/codex/blob/9d579813bbcafde0abd4010f57ac93eea0b1be2b/codex-rs/rollout/src/list.rs#L397
• thread/list already supports cursor pagination plus sourceKinds, cwd, archived, provider, sort, and search filters:
• https://github.com/openai/codex/blob/9d579813bbcafde0abd4010f57ac93eea0b1be2b/codex-rs/app-server-protocol/src/protocol/v2.rs#L4498-L4563

Related reports suggest this is not one narrow UI bug, but recurring drift between stored thread state and visible history/resume surfaces:

• Desktop hides local/project history despite stored state: #20419, #20608, #21076, #21128
• Desktop performance/history problems when scanning or hydrating large local histories: #20864, #18693
• IDE/extension history and project scoping requests: #3550, #15368, #19603, #20624
• Web/cloud history data-control concern when web conversations surface in App: #20476
• App-server visibility/documentation ambiguity: #16614, #16545

Proposed product/architecture direction:

1. Treat app-server thread/list plus thread/read/thread/turns/list as the canonical local history contract for rich clients.
2. Desktop and IDE history UIs should page by project/cwd and search against the server result, not only a preloaded global recent window.
3. CLI-created local interactive sessions should be visible in Desktop/IDE by default; source filters can hide them intentionally, but source should not imply a silo.
4. Avoid scan-all-on-startup behavior for large histories. Use indexed/paginated metadata first, hydrate turns only when needed.
5. For cloud/web, prefer explicit continuation/fork/delegation links such as continuedFrom, delegatedTo, forkedFrom, and home = local | cloud, rather than trying to make local and cloud share one mutable store.
6. If a thread exists but cannot hydrate, show a recoverable “stored but not loadable” state with action/log detail instead of making it disappear.

If this matches the intended direction, I can help next with a focused repro matrix across CLI/Desktop/IDE using thread/list evidence and current versions, or with an invited narrow patch/tests/docs around the local app-server contract. Happy to move this to a separate design issue if #21079 is too narrow.

The only issue is the fact that those of us running heaving agentic workflows do not need to see 100s of threads created by tools such as symphony for instance

yes please! i see my threads in /resume in cli but dont see the threads in codex app and it would be really useful to automatically have them opened in codex app even to they were started in cli

I patch codex plugin via codex cli after each codex plugin update: #15368

Adding a related workflow/use case that makes this feel like more than a history nicety: it creates an orchestration blind spot between the terminal CLI and the macOS app.

A common flow is:

1. Start codex from a terminal while already inside some project directory.
2. Let that CLI session continue, or forget that it exists.
3. Open the Codex macOS app later expecting it to be the central place to see current Codex work.
4. The project/session started from the CLI does not appear in the app's project list/sidebar, so the app gives no visible indication that this Codex work exists.

Expected behavior: when the macOS app opens, it should discover/index local Codex CLI sessions by their working directory and surface them in the appropriate project view. Ideally this should include both resumable historical CLI sessions and currently active/running CLI sessions, with clear source/status metadata such as CLI, running, idle, or resumable.

Why this matters: for users who switch between terminal Codex and the macOS app, the app is naturally the orchestrator/dashboard for ongoing Codex work. If CLI-started sessions are invisible there, it is easy to lose track of active work, duplicate effort, or assume nothing is running for a project when a CLI session already exists.

A good implementation could still avoid overwhelming users with every generated/tool-created session by adding filters or source grouping. The important part is that native Codex CLI sessions should not be silently missing from the desktop app's view of local projects and sessions.

Adding a related workflow request that feels like the missing explicit bridge between the CLI/TUI and Desktop app.

Current state:

• codex resume <SESSION_ID> works well from the CLI.
• The Desktop app can show prior threads when the right project/cwd is added and the thread is discoverable through the sidebar filters.
• But there does not appear to be a first-class “open this exact session in the app” path from the CLI/TUI, nor an obvious Desktop UI for pasting/entering a known session/thread ID and attaching it to the right project context.

Requested behavior:

1. CLI/TUI command to open a session in Codex Desktop

Example shell command shape:

codex app resume <SESSION_ID>
codex resume <SESSION_ID> --app
codex app open-session <SESSION_ID>

This should also be available as a slash command from inside the CLI/TUI, not only as a shell command.

Example slash command shape:

/open-app
/open-app <SESSION_ID>
/open-in-app
/open-in-app <SESSION_ID>

Useful behavior:

• With no argument, open the current CLI/TUI session in Codex Desktop.
• With a session ID, open that specific session in Codex Desktop.
• If the app cannot resolve the session into a visible project/thread, show a clear attach/import flow instead of failing silently.

Expected result: Codex Desktop opens directly to that resumable thread, rather than requiring the user to find it manually in the sidebar/history filters.

1. Desktop UI to resume/import by session ID

The app should have a small explicit action such as:

• “Resume from session ID”
• “Open existing thread”
• “Import/attach session”

This would let users paste a known SESSION_ID from /status, codex resume, logs, or ~/.codex/sessions, then have the app resolve it and open it if valid.

1. Clear project/remote binding during resume

When the session belongs to a local cwd, worktree, or remote project, the app should show what it is about to bind to:

• local path / cwd
• app project
• worktree, if applicable
• remote host/project, if applicable
• source surface: CLI, Desktop, IDE, app-server, automation

If there is ambiguity, the app should ask where to attach/open the thread instead of silently hiding it or creating a new project/thread.

Why this matters:

For CLI-heavy users, the Desktop app naturally becomes the dashboard for ongoing Codex work. A session ID is already the precise handle for resuming in the CLI, so there should be an equivalent “open this exact Codex work in the app” path. This would also make remote/project session continuity less dependent on sidebar filters, cwd heuristics, or manual discovery.

This issue matches a real workflow gap I hit today.

I created a local Codex project folder, added it to Codex Desktop as an existing project, and expected active Codex/OpenClaw CLI/app-server work against that folder to appear as threads under the Desktop project. From the user side, the mental model was: “Blessed is the project room, so all Codex runs for Blessed should be visible there.”

Instead, the work was happening successfully on disk and in local Codex session/app-server history, but it was not visible as project threads in the Desktop sidebar. That made the agentic coding process feel opaque: files changed, builds ran, screenshots existed, but the human operator lost the live thread/context.

The core product need is not just “import old CLI history.” It is continuity between Codex surfaces:

• Desktop project = visible workshop / project room
• CLI/app-server/OpenClaw runs = execution paths
• User expectation = all runs associated with the same folder/project should be discoverable as threads in that project

This matters because Codex Desktop’s biggest UX unlock is making agent work legible, spatial, and reviewable. When runs disappear into CLI/session stores, the user loses confidence and context even if the agent completed the task correctly.

A good version of this might be:

• auto-index CLI/app-server sessions by cwd when a project folder is registered
• expose an “Attach/import local Codex sessions for this folder” action
• support opening a known thread/session id in Desktop and associating it with a project
• show non-Desktop-originated runs with a source label like CLI, IDE, OpenClaw, app-server

Happy to provide local details if useful.

Codex CLI sessions are available in the Codex desktop app. However, you need to add the corresponding project in Codex desktop app if you want them to appear there. The app does not display sessions for projects that you have not previously added or have removed.

Thanks, that makes sense — appreciate the clarification.

I think what we’re running into may be a slightly different case around agentic / orchestrated coding sessions.

In this workflow, the user-facing project is added in Codex Desktop as /Users/amz/projects/blessed, but the long-running agent session was originally launched from an OpenClaw workspace root:

/Users/amz/.openclaw/workspace

From there, the agent did substantial work inside the Blessed project by running commands with /Users/amz/projects/blessed as the working directory: creating files, editing Swift code, generating the Xcode project, building, testing, launching the simulator, and saving screenshots/artifacts.

The user-facing symptom is: in Codex Desktop, under the added Blessed project, it says there are no chats, even though a long agentic coding session just created and modified that project.

So from the human’s perspective, this was clearly “the Blessed project session.” But Desktop appears to index/group the session by the original session cwd, rather than the project where the work actually happened.

That makes sense technically, but it means agentic sessions can become invisible from the project where the user expects to find them. In orchestrated workflows, the agent may be born in a home/workspace directory, then operate across one or more real project roots.

What we were hoping for is some way for Codex Desktop to understand or expose that relationship, for example:

• attach/import/reassign an existing CLI/OpenClaw session to a Desktop project
• infer project association from touched files or per-command working directories
• show “related sessions” when a session materially operated inside a project folder
• allow an agent/orchestrator to declare the active project root for Desktop indexing

Does that match how sessions are currently indexed? Happy to share local details if useful.

Yes, all clients (desktop app, IDE extension, TUI) assume that the thread's original cwd indicates which project it is part of. And to clarify, indexing occurs within the core harness, not in the app.

Are you able to change your workflow such that the main OpenClaw orchestrator agent switches to the target project directory before creating the project thread?

Yes, we can adjust our workflow so project-specific OpenClaw/Codex threads are created with the target project directory as the initial cwd. That should solve the immediate Blessed-style case.

I think the remaining gap is for orchestrator-born sessions that may start in a home/workspace context and then intentionally operate inside one or more project roots. For those, it would be useful if the core harness exposed an explicit way to declare or attach a project root for indexing, rather than relying only on original cwd.

So the current behavior makes sense technically, and we can work with it. A harness-level project association API or metadata field would help reduce ambiguity for orchestrated workflows and make cross-surface continuity easier to reason about.

I met it today, how it works? I'm not an expert, so I could not even try to fix it.