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.

I can reproduce the same issue on Windows 11 with WSL2.

A remote-created thread runs correctly and is stored locally, but it does not appear under the corresponding project in the Codex Desktop sidebar.

Environment:

• Windows 11
• WSL2 Ubuntu
• Codex CLI: 0.145.0-alpha.30
• Project located inside the WSL filesystem, for example /home/<user>/repos/<project>
• Flow: another trusted device -> Codex Remote -> Windows Codex Desktop host using WSL2

What I verified:

• The thread is created successfully and runs in the expected WSL working directory.
• It exists in the Desktop SQLite database under .codex/sqlite/state_5.sqlite.
• Its rollout file exists under /mnt/c/Users/<user>/.codex/sessions/<date>/rollout-<timestamp>-<thread-id>.jsonl.
• It can be opened directly with codex://threads/<thread-id>.
• Registering the WSL project through the supported codex://new?path=... flow does not make the thread appear in the sidebar.

The missing state appears to be the UI/project association. For the affected thread, these bindings were not created:

• thread-project-assignments
• projectless-thread-ids
• thread-workspace-root-hints

So the thread itself is intact, but the sidebar has no project binding it can use to display it.

This looks like the same underlying indexing/association bug, now also reproducible on Windows + WSL2 rather than only macOS.

I can reproduce this exact failure on macOS with a mobile Remote-created thread. This occurrence adds a useful persistence detail: the app-server rewrites a local metadata repair back to the invalid value.

Environment

• Codex Desktop: 26.519.41501 (build 3044)
• macOS: 26.5.2, arm64
• Flow: ChatGPT mobile -> Codex Remote -> local Mac host -> existing project in a Codex-managed worktree
• Affected thread's stored cli_version: 0.146.0-alpha.9.2

User-visible behavior

1. The task was created from mobile Remote and ran normally on the Mac.
2. Its complete conversation and work remain available.
3. Codex Desktop's normal task list/sidebar omits it.
4. Listing recent Desktop threads also omits it, even after the thread was active again today.
5. Direct navigation by the redacted thread ID succeeds immediately and opens the complete conversation.

This is not transcript loss and not a missing working directory.

Sanitized host-side evidence before repair

state_5.sqlite row exists: yes
archived: 0
source: vscode
thread_source: NULL
model_provider: openai
cwd: ~/.codex/worktrees/<id>/<repo>
cwd exists: yes
rollout JSONL exists: yes
session_index.jsonl entry exists: yes
direct navigation result: navigated=true
normal Desktop thread list contains the thread: no

Nearby normal, visible user threads in the same database have:

source: vscode
thread_source: user

Repair/backfill observation

After making a SQLite backup, I changed only the affected row from thread_source=NULL to thread_source=user.

• The update applied successfully.
• The in-memory Desktop sidebar/list did not refresh.
• Shortly afterward, the app-server wrote the row back to thread_source=NULL.

This suggests the invalid classification is being regenerated from another durable source or cached thread metadata. A one-time SQLite edit is therefore neither sufficient nor durable.

Expected product behavior

• Mobile Remote-created user threads should be persisted as normal user threads and appear in the host Desktop sidebar.
• Desktop listing should not hide an otherwise valid, unarchived thread solely because thread_source is null.
• Startup/backfill should recover this classification from the existing rollout/session index and refresh the sidebar.
• If metadata is incomplete, the UI should surface the thread in a recoverable state instead of making it discoverable only by ID.

Thread ID, repository name, account information, absolute paths, and transcript content are intentionally redacted.

I can confirm this remains reproducible on macOS with the current ChatGPT/Codex desktop app, and I have a before/after release boundary from the same machine that may help isolate the regression.

Environment

• ChatGPT/Codex desktop: 26.803.41515 (bundle build 6321)
• macOS 26.4.1 (25E253), Apple Silicon / arm64
• Flow: ChatGPT iOS -> Codex Remote -> local Mac host -> existing local project
• Same account, workspace, host, and project on both clients

Current reproduction

On August 7, I created three tasks from ChatGPT iOS Remote in the same existing local project.

• All three ran normally on the Mac and remain visible on iOS.
• None appears in the Mac project's sidebar, including while the tasks were running and after completion.
• Desktop-created tasks in the same project continue to appear normally.

Read-only host checks show that each missing Remote-created task:

• exists in ~/.codex/state_5.sqlite with archived=0;
• has the correct, existing project cwd;
• has an intact rollout JSONL;
• is returned by the desktop app's thread-list service with the correct local project ID and an idle/loadable status;
• has source=vscode and thread_source=NULL;
• is absent from thread-project-assignments and from that project's sidebar-project-thread-orders.

This is not task loss, Remote execution failure, or an incorrect project path. The missing step is Desktop sidebar registration/order insertion.

Before/after boundary

The same machine has older Remote-created tasks from July 14–22. Those older tasks have the same relevant persisted shape:

• source=vscode
• thread_source=NULL
• correct project cwd
• no explicit thread-project-assignments entry

However, every one of those older Remote-created tasks is present in the project's persisted sidebar-project-thread-orders, and they were surfaced by Desktop.

The local app logs establish this release boundary:

• Last known working Remote-created sample: July 22, under desktop 26.721
• Desktop updated from 26.721.41059 to 26.727.40816 on July 31
• First known failing Remote-created sample: August 3, under 26.727.51351
• Every Remote-created sample from August 3 onward is absent from sidebar order
• Current 26.803.41515 still reproduces

Desktop-created tasks after July 31 are still inserted into sidebar order, so this is specific to externally/Remote-created tasks rather than a general list cap or project-order failure.

Likely regression

The evidence points to the 26.727 Desktop sidebar/catalog changes no longer registering newly synchronized Remote tasks in the desktop-owned project order. thread_source=NULL is not independently causal because the older working Remote tasks have the same value; it appears to be a marker of the Remote creation path whose missing explicit association was previously tolerated or backfilled.

There were no Remote-created samples on this machine between July 23 and August 2, so a coincident iOS/backend change cannot be excluded absolutely. However, the tasks still arrive on the Mac with the same metadata, remain loadable, and resolve to the correct project through the desktop service. That makes the Mac sidebar ingestion path the stronger explanation.

Expected behavior: a task created through iOS Remote for an existing local project should be registered in the host Desktop sidebar exactly like a task created from Desktop. If explicit sidebar metadata is missing, Desktop should fall back to the durable task cwd/project inference already used by its thread-list service and backfill the association.

I can confirm this still reproduces on current macOS Desktop build 26.803.61601 (bundle build 6396).

Impact / severity: I would rate this as high severity for users who rely on Remote. Nearly every task I start through Remote on either iPhone or iPad is affected. I use Codex heavily across devices, so when I return to Desktop, the project history is systematically incomplete. I have to manually discover and pin each missing task, and until I do, the UI gives the reasonable impression that work may have been lost. This breaks the core cross-device workflow rather than an occasional edge case.

This occurrence adds two useful details:

1. It is not limited to mapping a temporary worktree path back to a project. The affected Remote-created tasks have the canonical local project cwd and are returned by the Desktop thread-list service with the correct local project ID.
2. The tasks have complete histories and can be opened through direct thread read/navigation, but remain represented as notLoaded and do not reliably appear in their project sidebar. Pinning makes them accessible, but does not repair normal project grouping.

The local sidebar catalog also appears stuck rather than merely delayed:

local_thread_catalog rows: 57
newest catalog row: 2026-07-17
initial_build_complete: 0
watermark_updated_at: NULL
last_full_reconciled_at: NULL
observation_sequence: 618

Newer Remote-created tasks exist in the authoritative state and are returned by the app's task-list service, but they are absent from this catalog.

I also inspected the packaged Desktop JavaScript. The turn/started notification handler effectively does:

if conversation is missing:
    log "Received turn/started for unknown conversation"
    break

It does not hydrate the conversation, buffer the event, or retry it. By contrast, the thread/status/changed handler has a path that calls hydrateActiveThread(threadId) for a missing active thread.

That suggests a two-stage failure:

Remote task starts
→ turn/started arrives before or without thread/started
→ Desktop drops the event because the conversation is unknown
→ thread later exists in thread/list
→ sidebar catalog does not reconcile/backfill it
→ task remains notLoaded and missing from its project group

Possible fix direction:

• Buffer or hydrate unknown turn/started conversations instead of dropping the event.
• Reconcile missing current tasks from thread/list into the sidebar catalog.
• Detect and repair a catalog that remains at initial_build_complete = 0.
• Add an out-of-order test where turn/started arrives before, or without, thread/started.

Possibly related conversation-initialization race: #18471
Related stalled sidebar catalog report: #35088

Thread IDs, task titles, project names, account details, and absolute paths are intentionally omitted.

cc @etraut-openai

Confirming the same user-facing problem on macOS with ChatGPT on iPhone. Whenever I start a new Codex chat through Remote Control on my phone, the task never appears in the macOS Codex sidebar. The task continues to work on mobile, but because it is not discoverable in the desktop app I am forced to finish the work from my phone instead of handing it back to the Mac.

Expected: a task created through mobile Remote Control should appear under the same project in the macOS Codex sidebar and be resumable there.

Actual: the mobile-created task remains absent from the desktop UI. This has happened consistently rather than as a one-off refresh delay.

Additional Windows reproduction (observed 2026-08-21):

Environment

• Codex Desktop for Windows: 26.818.31338
• ChatGPT/Codex iOS: 1.2026.209
• Flow: iOS Remote -> connected Windows Codex Desktop host -> existing local project

Observed behavior

1. Start a task from iOS Remote inside an existing project.
2. The task is created and runs normally. It is visible on iOS and remains searchable by its auto-generated title on Windows.
3. It does not appear in the Windows Recent/Active list, so completed remote work can be missed.
4. Searching for the exact generated title and opening the task makes it appear in Recents.
5. Restarting the Windows app does not repair the list.
6. Signing out and back into Codex Desktop once restores synchronization. Subsequent tasks completed from iOS then appear at the top normally without another sign-out.
7. This has not occurred for tasks created directly on the Windows desktop; it was specific to tasks originating from iOS Remote.

This suggests the thread data is preserved but the Windows recent-thread/project index or session synchronization becomes stale. The sign-out/sign-in recovery appears to force a full rehydration.

Impact
Remote is used to start fixes while away from the computer, then review/test/deploy them later on desktop. If completed tasks disappear from the visible pending/recent workflow, users can miss review work or create duplicate tasks.

A self-healing reconciliation or a user-facing “refresh/reindex conversations” action would be preferable to requiring reauthentication.