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

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

• #24173
• #24184
• #23979
• #24178
• #24136

Powered by Codex Action

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.

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.

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.

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

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

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

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

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

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

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

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

@etraut-openai
Please review

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.

@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?

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.

@etraut-openai

I've figured it out now, after playing around with it.

To solve my problem:
In the left-hand-side, click the three docs (...) and then switch from "organize sidebar by project" to "organize sidebar by chronological list".

<img width="395" height="350" alt="Image" src="https://github.com/user-attachments/assets/cd5b10c9-e9db-4a57-b780-7e87db316857" />

Now, repeat the same tests, where i start random sessions in random projects, using both codex cli and mobile.
Now, they instantly appear on top of the list on MacOS app.

This is exactly what i wanted, since that's the way to show all of my codex sessions on this computer, without me doing any manual work of adding each project/folder.

So the real problem is specific to "organize sidebar by project" which won't show these sessions (codex cli or mobile), unless the project/folder is already added in MacOS app, and then the sessions appear.

Cheers!