Mobile remote-created worktree thread is not associated with project in Codex Desktop sidebar

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

• #23268
• #23351
• #22796

Powered by Codex Action

I’m seeing the same issue from the ChatGPT iOS app.

Environment/details I can confirm:

• ChatGPT iOS app: 1.2026.125
• Device: iPhone13,1
• Flow: ChatGPT mobile app -> Codex remote connection -> Mac / Codex Desktop host
• Same ChatGPT account and workspace on both mobile and Mac
• Same host and same project selected
• Tasks started from mobile do run and make file changes successfully
• After that, the corresponding chat/thread does not appear in Codex Desktop on the Mac
• Refreshing/reopening the apps does not reliably make the thread appear

This makes it look like the mobile-created Codex thread is real and can execute on the host, but Codex Desktop is not associating it with the visible project/thread history. From the user point of view it feels like the Codex chats “disappear” after being started on mobile, even though the file changes were actually applied.

Expected behavior: a task/thread started from ChatGPT mobile through remote access should appear in the same project/thread list in Codex Desktop so it can be resumed from the Mac.

This is blocking because mobile-started tasks become hard to inspect or continue later from Desktop.

I can confirm a very similar failure mode on Windows, with one extra detail that may help narrow down the indexing/backfill path.

Environment

• OS: Windows
• Codex CLI: codex-cli 0.141.0
• Affected session session_meta.cli_version: 0.140.0-alpha.19
• Current locally-created Desktop sessions show session_meta.cli_version: 0.142.0-alpha.1
• Flow: ChatGPT mobile app -> Codex remote connection -> local Codex Desktop host -> existing project thread

User-visible behavior

A project thread that was first started from mobile briefly appeared in Codex Desktop, then disappeared from the Desktop project/sidebar view after restarting Codex Desktop.

The conversation was not deleted. Its rollout JSONL transcript still existed locally under .codex/sessions/..., and history.jsonl also still referenced the same session id.

Local state before repair

For the affected thread:

rollout JSONL exists: yes
state_5.sqlite threads row exists: yes
archived: 0
source: vscode
model_provider: openai
thread_source: NULL
session_index.jsonl entry: missing

Other user-visible local project threads on the same host were generally indexed as:

model_provider: customapi
thread_source: user

So this looked like the thread existed, but was filtered out / not classified as a normal user thread in the Desktop thread list.

Important additional observation

Updating only state_5.sqlite was not durable. I first changed the affected row to:

model_provider: customapi
thread_source: user

and appended the missing session_index.jsonl entry. The Desktop list still did not show it immediately, and shortly afterward the SQLite row was written back to the old values:

model_provider: openai
thread_source: NULL

The cause appears to be that the rollout JSONL session_meta line also had:

"model_provider": "openai"

After updating all three durable sources together:

1. append the missing session_index.jsonl entry
2. update state_5.sqlite.threads to model_provider=customapi, thread_source=user
3. update the rollout JSONL first session_meta.model_provider to match the local visible provider

Codex Desktop's thread list started showing the thread again.

Why this may be useful

This suggests the Desktop/app-server may be rebuilding or refreshing state_5.sqlite.threads from rollout session_meta, and that mobile/remote-created threads can be persisted with a provider/source shape that later causes them to disappear from the Desktop-visible user/project thread list.

A robust product fix probably needs to treat these fields as recoverable/migratable metadata, not as a reason to hide an otherwise valid unarchived local user thread. At minimum, startup/backfill could repair missing session_index.jsonl rows and normalize thread_source / provider metadata for mobile remote-created local project threads, or avoid filtering them out solely because those fields differ from the current Desktop provider.

All paths/thread ids above are intentionally redacted, but I can provide the exact local field layout if useful.

I am seeing a closely related variant on macOS.

A thread is visible from Codex mobile / remote history, but it is not showing where expected in Codex Desktop for the corresponding project. The underlying local data is intact; the issue appears to be Desktop project/sidebar association when the recorded cwd is a Codex-managed worktree path that no longer exists.

Sanitized local evidence:

• thread id: <redacted>
• Codex session meta:
• originator: Codex Desktop
• source: vscode
• cli_version: 0.142.0-alpha.6
• cwd: /Users/<user>/.codex/worktrees/cb17/dotfiles
• state_5.sqlite.threads:
• archived = 0
• source = vscode
• thread_source = NULL
• rollout_path points to an existing JSONL under ~/.codex/sessions/...
• session_index.jsonl has an entry for the thread.
• The recorded cwd no longer exists:
• /Users/<user>/.codex/worktrees/cb17/dotfiles -> missing
• The actual repo/worktree used later for recovery was:
• /Users/<user>/.codex/worktrees/9662/dotfiles

I audited local state and found this pattern:

• 444 total thread rows
• 16 active rows
• 5 active rows with cwd under ~/.codex/worktrees/...
• only 1 active row points at a missing cwd, and it is this affected thread
• 55 total worktree-backed rows historically
• 25 total worktree-backed rows point at missing cwd paths, but 24 are archived

So this looks like the product-visible failure occurs when a Codex-managed worktree thread remains unarchived after its worktree cwd is gone. Mobile/history can still surface the session from the rollout/index data, but Desktop does not map it back to the canonical project root.

Expected behavior:

If a local thread is unarchived and its rollout JSONL exists, Desktop should still surface it in a recoverable place even when the recorded Codex-managed worktree cwd is missing. Ideally Desktop would map the thread back to the canonical Git repository/project root, or show it in a "missing worktree / needs recovery" state rather than hiding it from the project sidebar.

I can reproduce this on macOS with an ordinary local checkout (not a Codex-managed worktree), which suggests the problem is broader than worktree-to-project mapping.

Environment

• Host: Intel Mac, macOS
• Codex standalone/app-server: 0.144.1
• Flow: ChatGPT Android app -> Codex Remote -> local Mac host
• Selected model for the mobile-created tasks: GPT-5.6-Sol
• Repository: private GitHub repository cloned to a normal path under /Users/<user>/Projects/<repo>

Reproduction and evidence

1. I selected the existing local project from ChatGPT Remote on Android.
2. I started two tasks from the phone.
3. Both tasks ran and their full conversations were persisted on the Mac.
4. Codex Desktop did not add either task to that project's sidebar, including after refresh/restart attempts.
5. The app-server thread listing could immediately find both threads with the correct project cwd. One was reported as notLoaded and the other as idle.
6. Navigating directly to a missing thread by its thread ID opened it successfully in Codex Desktop, with the complete mobile conversation intact.

This is therefore not data loss, a missing checkout, or an incorrect worktree path. The remote-created threads are present and associated with the exact existing project directory, but the Desktop project/sidebar view is not being invalidated, refreshed, or populated consistently.

Expected behavior

Every thread created through mobile Remote for a local project should appear automatically in that project's Desktop sidebar, including the first threads created for a newly opened project. A notLoaded remote-created thread should not be excluded if it is active, unarchived, and has a valid project cwd.

A useful implementation check may be whether Desktop subscribes to thread-created/thread-list-invalidated events from the remote-control app-server and re-queries the affected project, rather than relying only on its existing local sidebar cache.

---
This issue comment was generated by LazyCodex.
Tag: lazycodex-generated

I can reproduce this on macOS with Codex CLI/app-server 0.144.1, using an ordinary existing checkout rather than a Codex-managed worktree.

Flow:

• ChatGPT mobile -> Codex Remote -> local Mac host
• The mobile-created task ran normally and persisted its full rollout.
• The thread is absent from the host Codex Desktop project sidebar.
• Direct navigation by thread ID opens the complete thread successfully.

Sanitized host-side evidence:

state_5.sqlite row exists: yes
archived: 0
source: vscode
thread_source: NULL
cwd: ~/Projects/<group>/<repo>   # exact existing project root
rollout JSONL exists: yes
session_index.jsonl entry: missing

The affected thread is also absent from Desktop per-thread UI metadata (client-id/description/workspace-root-hint maps), while the app can still load it directly by ID.

A normal visible thread in the same installation is classified with thread_source=user. This strengthens the existing evidence that remote-created user threads can be durably stored but omitted from Desktop indexing/classification even when cwd is valid and no worktree mapping is involved.

Expected: a user thread created through Mobile Remote should be classified/indexed like other user threads and immediately appear in the host Desktop sidebar. Startup/backfill should also repair already-persisted unarchived threads with this metadata shape.

I did not edit SQLite/JSONL locally because the app-server may rebuild the row from durable metadata, and a supported product-side backfill is preferable.