Feature request: show local Codex CLI sessions in the desktop app

[coygeek]

Feature request

I would like the Codex desktop app to show, search, and open local sessions created from the standalone Codex CLI/TUI.

Problem

I often use Codex from the CLI directly on my computer, not from the Codex macOS app. Those CLI sessions are real local Codex work sessions, but when I later open the Codex desktop app, I cannot see them there.

This means the desktop app is not a unified view of my Codex work. It only shows the sessions it knows about, while my CLI-created sessions are effectively invisible from the app.

I am not reporting this as a data-loss bug. I understand the app may currently use a different session/indexing path than the standalone CLI. The request is for first-class product support for viewing ordinary CLI-created sessions inside the Codex app.

Local context

• Platform: macOS 26.5, arm64
• Codex desktop app: 26.519.41501, bundle version 3044
• Codex CLI: codex-cli 0.133.0
• CODEX_HOME: default $HOME/.codex
• Local CLI session storage includes canonical rollout JSONL files under $HOME/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
• Local metadata exists in $HOME/.codex/state_5.sqlite, including threads.rollout_path, threads.source, threads.cwd, threads.title, threads.model, and related fields
• On this machine, state_5.sqlite currently has hundreds of local source='cli' thread rows, including hundreds of unarchived CLI sessions

The important bit: these sessions are not abstract or remote-only. They have local transcript files and local metadata, and the CLI can find/resume them. The desktop app just does not appear to expose them as part of its session/history UI.

Desired behavior

The Codex desktop app should provide a unified local session view that includes ordinary Codex CLI/TUI sessions created on the same machine/account.

At minimum, I would like to be able to:

• see CLI-created sessions in the desktop app history/sidebar
• search CLI-created sessions from the app
• open/read a CLI-created session from the app
• ideally resume or fork a CLI-created session from the app, if technically supported

Why this matters

For CLI-heavy users, Codex work is split across two surfaces:

• the CLI, where many real sessions are started and resumed
• the desktop app, which is useful for browsing, supervising, and managing work

Right now the desktop app has no visible connection to much of my CLI history. That makes the app less useful as a central workspace, because it cannot answer "what have I been doing in Codex?" unless the work started inside the app.

Possible implementation shapes

Any of these would solve the core problem:

• the app reads/indexes $HOME/.codex/state_5.sqlite and the rollout files referenced by threads.rollout_path
• the app reads/indexes $HOME/.codex/sessions directly, using the same lookup behavior as the CLI
• the CLI writes session metadata into a store the app already indexes
• the app offers an "Import local CLI sessions" or "Show local CLI sessions" option
• the app provides a read-only local session browser first, if full resume/fork support is not initially safe

The exact storage design is less important than having an official supported bridge between ordinary CLI-created sessions and the desktop app UI.

Related issues

• Sync CLI and app-server sessions #14722 asks for syncing between CLI and app-server sessions.
• Desktop app does not show older local CLI/TUI sessions; pinned chats still open, but unpinned CLI sessions never appear in app #18737 reported a similar user-visible gap but was closed as duplicate of a Windows bug.
• Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540 is open and tracks local sessions present on disk but missing from desktop UI/search, though it is Windows-specific.
• ACP-spawned sessions don't appear in the Codex desktop app #16385 asked for a unified view for ACP-spawned sessions, but this request is about ordinary Codex CLI/TUI sessions, not ACP or a third-party orchestrator.

[github-actions]

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

• Codex App fails to read recent conversation #24173
• Codex Mobile report Codex run stopped #24184
• Codex Desktop 26.519.22136: local project conversation history missing after update, threads still exist in state_5.sqlite #23979
• Codex Desktop conversations become empty and resume fails with stale Windows path #24178
• Feature request: searchable local transcript history across sessions #24136

Powered by Codex Action

[coygeek]

I investigated this and have a candidate branch here:

https://github.com/coygeek/codex/tree/feat/local-cli-sessions-in-app

The branch changes app-server history listing so desktop-shaped thread/list requests with omitted or empty modelProviders include local interactive CLI sessions across providers, while explicit provider filters remain strict.

What I tested:

• CARGO_NET_GIT_FETCH_WITH_CLI=true GIT_CONFIG_GLOBAL=/dev/null just test -p codex-app-server
• CARGO_NET_GIT_FETCH_WITH_CLI=true GIT_CONFIG_GLOBAL=/dev/null just fix -p codex-app-server
• CARGO_NET_GIT_FETCH_WITH_CLI=true GIT_CONFIG_GLOBAL=/dev/null just fmt
• git diff --check
• Targeted app-server regressions for omitted modelProviders, empty modelProviders, strict explicit provider filtering, source filtering, and thread/read provider fallback behavior.
• Fresh disposable Tart VM validation: launched the desktop app against the branch-built local app-server first, then created three separate interactive codex CLI sessions afterward and verified the already-running app could find those sessions in history/search.
• Protocol cross-check: called thread/list with sourceKinds: ["cli"] and omitted modelProviders, then called thread/read for each new CLI session and confirmed each unique session prompt/response was readable.
• Additional codex-review passes after validation; one post-filtered source-history edge case was found, fixed, and reverified.

[etraut-openai]

This should already work. I use this workflow all the time, and it seems to work fine for me. Let's see if we can figure out why it's not working for you. Are you using a custom model provider? Could you run /feedback and post the session ID here? That will also upload the output of codex doctor, which will likely be useful for diagnosing this problem. You can run it yourself to see if it provides any useful hints.

[coygeek]

I dug into this more carefully, and I think I found the source of the mismatch.

This does not appear to be a custom-provider problem on my machine. codex doctor reports OpenAI as the active provider, ChatGPT auth is configured, the state DB is healthy, and the DB has many unarchived source=cli, model_provider=openai rows. Direct thread/list calls also return recent CLI-created rows.

I can also now confirm that the desktop left rail does show some CLI-created sessions when their cwd belongs to a project the desktop app already knows about. For example, after moving my Codex window back onto the visible display, I saw recent Terminal-created CLI test sessions under a known project in the left rail. That likely explains why this works in your workflow.

The remaining gap seems narrower:

• CLI sessions under an already-known desktop project can appear in the left rail.
• Fresh CLI sessions from $HOME / projectless cwd or from a newly-created git repo unknown to the desktop app can be present in SQLite and returned by app-server, but still not appear in a fresh desktop profile's left rail.

So I think the issue is not "CLI sessions are never visible." It is more like: the desktop sidebar is not a unified browser for arbitrary local CLI history; it appears to rely on desktop-maintained project/sidebar state when deciding what to project into the left rail.

That distinction reconciles the two observations: the workflow can work for known projects, while still failing for projectless or unknown-cwd CLI history.

[coygeek]

Here is a concrete repro/verification path for the narrower bug.

What to test

Test whether the desktop left rail discovers CLI-created sessions when the desktop profile has no saved project/sidebar state for that cwd.

Suggested clean-profile repro

Use the same installed app bundle and its bundled CLI for both the desktop app and Terminal-created sessions.

1. Create an isolated Codex profile:

export TEST_CODEX_HOME="$(mktemp -d)"
export TEST_ELECTRON_PROFILE="$(mktemp -d)"
mkdir -p "$TEST_CODEX_HOME"
cp "$HOME/.codex/auth.json" "$TEST_CODEX_HOME/auth.json"
cp "$HOME/.codex/config.toml" "$TEST_CODEX_HOME/config.toml" 2>/dev/null || true

2. Launch the desktop app first with that isolated state:

CODEX_HOME="$TEST_CODEX_HOME" \
CODEX_ELECTRON_USER_DATA_PATH="$TEST_ELECTRON_PROFILE" \
/Applications/Codex.app/Contents/MacOS/Codex

3. Confirm the desktop window actually renders the left rail before proceeding. In my repro, the fresh rail rendered and showed No chats.

4. After the app is already launched, create a Terminal-launched interactive CLI session from $HOME using the same app bundle's CLI. Use an obvious unique prompt marker, for example:

LEFT_RAIL_HOME_REPRO: reply exactly LEFT_RAIL_HOME_REPRO and stop.

This should be a normal interactive CLI session, not codex exec, so it persists as source=cli.

5. Relaunch or focus-refresh the same isolated desktop profile and check whether the marker appears in the left rail.

6. Repeat with a newly initialized git cwd that the desktop app has never opened:

UNKNOWN_REPO="$(mktemp -d)"
cd "$UNKNOWN_REPO"
git init
CODEX_HOME="$TEST_CODEX_HOME" /Applications/Codex.app/Contents/Resources/codex

Prompt marker:

LEFT_RAIL_GIT_REPRO: reply exactly LEFT_RAIL_GIT_REPRO and stop.

7. Verify storage/protocol independently:

sqlite3 "$TEST_CODEX_HOME/state_5.sqlite" \
  "select id, source, model_provider, archived, cwd, substr(preview,1,80) from threads where preview like 'LEFT_RAIL_%_REPRO%';"

Expected backend/storage result:

• source = cli
• model_provider = openai
• archived = 0
• cwd is $HOME for the first row and the new git cwd for the second row

8. Also verify app-server thread/list and thread/read against the isolated CODEX_HOME. The important filter shapes are:

• omitted modelProviders / sourceKinds
• modelProviders: [], sourceKinds: []
• modelProviders: ["openai"], sourceKinds: ["cli"]

In my run, both isolated CLI rows were returned by those app-server calls, and thread/read opened each row, but the fresh desktop left rail still showed No chats after relaunch.

Control case

As a control, run a CLI session from a project that the desktop profile already knows about. On my normal profile, CLI-created sessions from a known project did appear in the left rail. That is the behavior that likely explains why this works for some workflows.

Evidence from my run

• Codex macOS app bundle: 26.519.41501
• Bundled CLI used for the clean-profile proof: codex-cli 0.133.0-alpha.1
• Default codex doctor later reported active provider openai, ChatGPT auth configured, healthy state DBs, and no provider/connectivity failure.
• Default state had many unarchived source=cli, model_provider=openai rows.
• Default profile left rail showed CLI-created rows under an already-known project.
• Fresh isolated desktop profile did not show newly-created $HOME or unknown-git-cwd CLI rows, despite SQLite and app-server proving both were present and readable.

So the likely acceptance test is: seed or create unarchived source=cli, modelProvider=openai sessions in a fresh desktop profile with no existing project records, then assert the left rail does not remain No chats if unified local CLI history is intended behavior.

[coygeek]

@etraut-openai
Please review

[etraut-openai]

Yes, if you create a thread in the CLI that is not within a project that you've established in the app — or a project that you previously established but then removed removed in the app, then it will not appear in the app's left side panel. The same is true for threads in the app, so this isn't specific to the CLI. If you create a thread in the app under a project and then remove that project, that thread will no longer appear in the left side bar. If you then add that project back, all threads associated with that project will reappear.

[coygeek]

@etraut-openai thanks, that clarification helps. I want to make sure I understand the intended model correctly.

My workflow is often:

1. Start multiple Codex CLI sessions across many different projects/folders.
2. Open the Codex macOS app later.
3. Those sessions do not appear in the app unless the corresponding project/folder is already present in the app's Projects/left-rail state.
4. If I manually add that project/folder to the app later, the previously-created sessions for that folder then appear.

If that is accurate, then I think this is the core UX problem I am trying to report:

Codex sessions from CLI/mobile/app can be hidden by default unless the macOS app already has the associated project/folder registered.

From the user's perspective, the sessions already exist. They are stored locally, they can be resumed/read by Codex, and in some cases the backend/app-server can return them. But the macOS app makes them effectively invisible unless the user already knows which project folder to add to the app first.

That puts the burden on the user to remember or discover every folder where they have previously run Codex, manually add those folders as projects in the app, and only then see the associated session history. For a CLI-heavy workflow across dozens of repositories, that becomes painful very quickly.

I also confirmed that this is not just a CLI-specific issue. I see the same behavior with mobile-created sessions:

1. Start the Codex macOS app so mobile can target a local folder.
2. Start a new Codex session from mobile in a folder/project that is not currently in the macOS app's left rail.
3. Ask a question on mobile and wait for the session to finish.
4. Look at the macOS app: the session does not appear anywhere obvious.
5. Add that project/folder to the macOS app's left rail.
6. The mobile-created session then appears. In my screenshot, this is the "Find my menu bar apps." session.

So the issue seems broader than "CLI sessions do not appear." It is more like the app is project-filtering local history in a way that makes existing sessions look missing.

That feels surprising because the app looks like a central session/history surface, but it is actually behaving like a project-filtered view with no obvious way to discover sessions from unregistered projects.

If this project-scoped behavior is intentional, I think the app needs some first-class way to surface these sessions, for example:

• an "All local sessions" view
• an "Unregistered projects" or "Unknown folders" section
• automatic discovery of local CLI/mobile sessions
• a prompt to add projects when hidden sessions are detected
• search that can find sessions even when their project is not currently in the left rail

Otherwise, sessions can look missing even though they still exist and become visible later once the user manually adds the right folder.

Can you confirm whether this hidden-by-default behavior is intended product behavior, or a current implementation limitation?

[etraut-openai]

Thanks for describing your workflow. The feature request makes sense given that context.

I think it's safe to say that the current implementation isn't optimized for the workflow that you've described. I don't know how common it is. I'm interested to hear from other Codex users on this point.