Make Codex CLI sessions available in Codex desktop history

[lancewillett]

What feature would you like to see?

Make local Codex CLI sessions available as first-class threads in Codex desktop history, or provide an explicit “Import Codex CLI history” action.

Current behavior

Codex desktop onboarding successfully imported Claude Code history into the app. Native Codex CLI sessions are stored locally and resumable from the CLI, but they do not appear to be surfaced in Codex desktop history the same way.

Verified locally:

• codex resume --all can see prior Codex CLI sessions.
• Resuming a specific CLI session by ID works.
• The resumed session loaded the prior transcript and accepted a new prompt.
• Codex desktop history does not appear to show those Codex-native CLI sessions as first-class desktop threads.

Expected behavior

Codex desktop should index and display local Codex CLI sessions automatically, or offer an explicit import flow for Codex CLI history.

Why this matters

CLI and desktop are part of the same Codex product and account experience. Users expect Codex-native sessions to move between terminal and desktop more seamlessly than imported third-party sessions. This would make it easier to continue work across the CLI and desktop app without manually finding session IDs.

Environment

• Codex CLI: 0.128.0
• Platform: macOS
• Auth mode: ChatGPT login

[github-actions]

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

• Codex Desktop bug report: recent conversation history hidden/stale despite local DB containing threads #21076
• Codex Mac app hides unarchived local threads until they are messaged again #20959
• /goal-first sessions are missing from resume lists #20792
• Codex Desktop: chats disappear after update/import; imported threads open blank despite JSONL turns #20493

Powered by Codex Action

[lancewillett]

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.

[ForkAroundAndFindOut]

+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

[tiziano-contorno]

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:

  • codex/codex-rs/state/migrations/0001_threads.sql

    Lines 1 to 25 in 9d57981

    	CREATE TABLE threads (
    	id TEXT PRIMARY KEY,
    	rollout_path TEXT NOT NULL,
    	created_at INTEGER NOT NULL,
    	updated_at INTEGER NOT NULL,
    	source TEXT NOT NULL,
    	model_provider TEXT NOT NULL,
    	cwd TEXT NOT NULL,
    	title TEXT NOT NULL,
    	sandbox_policy TEXT NOT NULL,
    	approval_mode TEXT NOT NULL,
    	tokens_used INTEGER NOT NULL DEFAULT 0,
    	has_user_event INTEGER NOT NULL DEFAULT 0,
    	archived INTEGER NOT NULL DEFAULT 0,
    	archived_at INTEGER,
    	git_sha TEXT,
    	git_branch TEXT,
    	git_origin_url TEXT
    	);
    	CREATE INDEX idx_threads_created_at ON threads(created_at DESC, id DESC);
    	CREATE INDEX idx_threads_updated_at ON threads(updated_at DESC, id DESC);
    	CREATE INDEX idx_threads_archived ON threads(archived);
    	CREATE INDEX idx_threads_source ON threads(source);
    	CREATE INDEX idx_threads_provider ON threads(model_provider);

  • codex/codex-rs/rollout/src/list.rs

    Line 397 in 9d57981

    /// Directory layout: `~/.codex/sessions/YYYY/MM/DD/rollout-YYYY-MM-DDThh-mm-ss-<uuid>.jsonl`

• thread/list already supports cursor pagination plus sourceKinds, cwd, archived, provider, sort, and search filters:

  • codex/codex-rs/app-server-protocol/src/protocol/v2.rs

    Lines 4498 to 4563 in 9d57981

    	#[derive(Serialize, Deserialize, Debug, Clone, PartialEq, JsonSchema, TS)]
    	#[serde(rename_all = "camelCase")]
    	#[ts(export_to = "v2/")]
    	pub struct ThreadListParams {
    	/// Opaque pagination cursor returned by a previous call.
    	#[ts(optional = nullable)]
    	pub cursor: Option<String>,
    	/// Optional page size; defaults to a reasonable server-side value.
    	#[ts(optional = nullable)]
    	pub limit: Option<u32>,
    	/// Optional sort key; defaults to created_at.
    	#[ts(optional = nullable)]
    	pub sort_key: Option<ThreadSortKey>,
    	/// Optional sort direction; defaults to descending (newest first).
    	#[ts(optional = nullable)]
    	pub sort_direction: Option<SortDirection>,
    	/// Optional provider filter; when set, only sessions recorded under these
    	/// providers are returned. When present but empty, includes all providers.
    	#[ts(optional = nullable)]
    	pub model_providers: Option<Vec<String>>,
    	/// Optional source filter; when set, only sessions from these source kinds
    	/// are returned. When omitted or empty, defaults to interactive sources.
    	#[ts(optional = nullable)]
    	pub source_kinds: Option<Vec<ThreadSourceKind>>,
    	/// Optional archived filter; when set to true, only archived threads are returned.
    	/// If false or null, only non-archived threads are returned.
    	#[ts(optional = nullable)]
    	pub archived: Option<bool>,
    	/// Optional cwd filter or filters; when set, only threads whose session cwd
    	/// exactly matches one of these paths are returned.
    	#[ts(optional = nullable, type = "string | Array<string> | null")]
    	pub cwd: Option<ThreadListCwdFilter>,
    	/// If true, return from the state DB without scanning JSONL rollouts to
    	/// repair thread metadata. Omitted or false preserves scan-and-repair
    	/// behavior.
    	#[serde(default, skip_serializing_if = "std::ops::Not::not")]
    	pub use_state_db_only: bool,
    	/// Optional substring filter for the extracted thread title.
    	#[ts(optional = nullable)]
    	pub search_term: Option<String>,
    	}
    	#[derive(Serialize, Deserialize, Debug, Clone, PartialEq, Eq, JsonSchema)]
    	#[serde(untagged)]
    	pub enum ThreadListCwdFilter {
    	One(String),
    	Many(Vec<String>),
    	}
    	#[derive(Serialize, Deserialize, Debug, Clone, Copy, PartialEq, Eq, JsonSchema, TS)]
    	#[serde(rename_all = "camelCase")]
    	#[ts(rename_all = "camelCase", export_to = "v2/")]
    	pub enum ThreadSourceKind {
    	Cli,
    	#[serde(rename = "vscode")]
    	#[ts(rename = "vscode")]
    	VsCode,
    	Exec,
    	AppServer,
    	SubAgent,
    	SubAgentReview,
    	SubAgentCompact,
    	SubAgentThreadSpawn,
    	SubAgentOther,
    	Unknown,
    	}

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: macOS Desktop sidebar hides older local conversations despite existing thread state #20419, Codex Desktop macOS project sidebar hides unarchived local threads even though SQLite/session files are intact #20608, Codex Desktop bug report: recent conversation history hidden/stale despite local DB containing threads #21076, Codex Desktop silently hides project conversations outside the global recent-50 window #21128
• Desktop performance/history problems when scanning or hydrating large local histories: Codex Desktop App becomes laggy because it scans all ~/.codex/sessions rollout files instead of respecting Desktop-visible session index/state #20864, Desktop performance collapses in profiles with a few very large local conversation histories (typing, scrolling, thread list, random exits) #18693
• IDE/extension history and project scoping requests: Scope Codex chats to VS Code projects/workspaces #3550, Increase cap of sessions in VS Code extension #15368, VS Code extension session sidebar should match Codex CLI resume picker semantics #19603, VS Code extension silently fails to open older local sessions #20624
• Web/cloud history data-control concern when web conversations surface in App: Ability to delete or clear Codex Web conversation history, especially when it syncs into Codex App #20476
• App-server visibility/documentation ambiguity: Clarify expected codex app-server thread visibility in Desktop history and why custom-client threads are recorded as vscode #16614, thread/list filesystem fallback can hide older matching threads after hitting 10,000-file scan cap #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.

[8th-block]

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

[andras-gyarmati]

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

[iqdoctor]

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

[coygeek]

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.

[Absorber97]

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.

2. 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.

3. 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.

[amzzzzzzz]

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.