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

Summary

A thread created from ChatGPT mobile through Codex remote access exists locally and can be opened by deeplink, but it does not appear in the Codex Desktop project sidebar.

This looks like a project/thread association issue rather than data loss.

Environment

Codex Desktop: 26.513.31313, build 2867
Codex CLI: 0.131.0-alpha.9
OS: macOS
Flow: ChatGPT mobile app -> Codex remote connection -> local Desktop host
Thread mode: worktree

Steps to Reproduce

On ChatGPT mobile, connect to a local Codex Desktop host through remote access.
Open an existing project from that host.
Start a new thread in worktree mode.
Let the thread run normally.
On the Desktop app, open the same project sidebar.
Try to find the newly created thread.

Expected Behavior

The thread created from mobile remote access should appear in the same project sidebar on Codex Desktop.

Actual Behavior

The thread does not appear in the Desktop project sidebar.

However, the thread is present in local state and can be opened directly via deeplink:

codex://threads/<redacted-thread-id>

Local Evidence

The thread exists in the local SQLite state:

id=<redacted-thread-id>
archived=0
cwd=/Users/<user>/.codex/worktrees/<worktree-id>/<repo-name>
thread_source=NULL

The rollout JSONL also exists locally:

/Users/<user>/.codex/sessions/<date>/rollout-<timestamp>-<redacted-thread-id>.jsonl

The issue appears to be that the thread is not associated with the canonical project root:

/Users/<user>/<projects>/<repo-name>

In this case, the thread was created under a temporary Codex worktree path, but the Desktop sidebar did not map it back to the original project.

Related Issues

Possibly related:

Notes

This is not a request for a local workaround. The expected product behavior is that threads created through mobile remote access remain visible in the corresponding Desktop project sidebar.

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

"Fork into New Worktree" groups the new thread under the wrong project in the sidebar for remote workspaces #23268
Remote mobile-started and CLI-started threads are not listed in the mobile app for resume #23351
Codex Desktop project sidebar shows No chats while local sessions still exist #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:

append the missing session_index.jsonl entry
update state_5.sqlite.threads to model_provider=customapi, thread_source=user
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

I selected the existing local project from ChatGPT Remote on Android.
I started two tasks from the phone.
Both tasks ran and their full conversations were persisted on the Mac.
Codex Desktop did not add either task to that project's sidebar, including after refresh/restart attempts.
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.
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

The task was created from mobile Remote and ran normally on the Mac.
Its complete conversation and work remain available.
Codex Desktop's normal task list/sidebar omits it.
Listing recent Desktop threads also omits it, even after the thread was active again today.
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:

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

@etraut-openai

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

Start a task from iOS Remote inside an existing project.
The task is created and runs normally. It is visible on iOS and remains searchable by its auto-generated title on Windows.
It does not appear in the Windows Recent/Active list, so completed remote work can be missed.
Searching for the exact generated title and opening the task makes it appear in Recents.
Restarting the Windows app does not repair the list.
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.
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.

I reproduced this consistently and investigated the app-server notification path. This appears broader than a worktree/project-root association problem: my affected threads used the normal project cwd but still failed to appear in Codex Desktop.

Environment

Codex Desktop: 26.820.80927, build 7271
Bundled Codex CLI: 0.150.0-alpha.8
ChatGPT iOS Remote client observed in logs: 1.2026.209
macOS 26.6.2

Persistence evidence

I reproduced six affected remote-created threads. All six were successfully persisted:

Each thread existed in the local SQLite state database.
Each corresponding rollout JSONL file existed.
Their history and user messages were intact.
They were not archived.
Restarting Codex Desktop did not restore them to the sidebar.

This confirms that the failure is in live desktop discovery/indexing rather than thread creation, synchronization, or persistence.

Root cause

An ordinary app-server thread/start automatically attaches a thread listener only to the connection that issued the request.

With Remote Control, the iOS client is a separate RemoteControl connection from the local desktop’s stdio connection. Therefore:

The iOS Remote connection sends thread/start and becomes subscribed to the new thread.
The desktop receives the globally broadcast thread/started notification.
Thread-scoped events—including turn/started and the user-message item/started event—are sent only to subscribed connections.
The local desktop stdio connection is not subscribed, so it misses the events its task index uses to retain the new thread in the project sidebar.
Restarting does not repair the entry because the desktop does not reconstruct these missing sidebar entries from persisted orphaned threads.

Git history indicates that the requester-only subscription behavior predates Remote Control. The Remote Control transport was added in 73dab2046f without adding a companion subscription for the already-connected local stdio client. This therefore appears to have been an integration gap since the original Remote Control implementation, rather than a recent removal of working app-server behavior.

Proposed fix

Track each initialized app-server connection’s origin. When thread/start originates from a RemoteControl connection, also attach all live local Stdio connections to that thread.

The proposed implementation intentionally:

Preserves the requesting Remote Control subscription.
Adds only local stdio companions.
Does not subscribe unrelated WebSocket or in-process clients.
Does not enable experimental raw events for the desktop companion.
Makes no public protocol or schema changes.

Validation

I have a local implementation with:

Positive and negative connection-selection unit tests.
An end-to-end test running a real app-server subprocess and simulated Remote Control WebSocket client.
Explicit red/green proof: without the companion subscription, the desktop receives thread/started and status notifications but times out waiting for turn/started; with the fix, it receives turn/started and the complete remote user-message item/started.
Target-native automatic environment coverage for split app-server/exec-server configurations.
Full codex-app-server suite: 1,393 passed, 1 skipped, zero failures.
Scoped Clippy, formatting, and repository argument-comment lint checks passing.

Recovery for existing affected tasks

Existing affected tasks can be restored to the Desktop sidebar by opening each task through search or direct task navigation. This hydrates the sidebar entry without modifying SQLite. Restarting Codex Desktop alone does not do so.

This also appears to explain the behavior reported in #32273.

I have preserved the tested patch locally. Per the repository contribution policy, I have not opened an external pull request, but I can provide the commit or a formatted patch if a maintainer would find it useful.

Follow-up on 7 September to my 7 August report: phone-started tasks still appear missing from the Mac project sidebar in Manual order.

Update after testing Search chats: search finds the affected task, and selecting it extends the project list to reveal it. This narrows my reproduction to ordering and list expansion: the task is discoverable below the initially visible part of the project list. The earlier apparent disappearance should not be read as proof that the task was removed from the project entirely.

Sorting control and discoverability: the user-facing control is hover over the Projects heading → Project sidebar options → Sort chats by → Last updated. The options button appears on hover. I did not realize the app allowed this ordering to be changed until the location was pointed out, despite investigating the apparent missing-session problem for weeks. This makes an ordering problem look like failed cross-device synchronization. Please make the active sort mode and its control easier to discover, alongside fixing the inconsistent initial placement of Remote-created tasks. Changing to Last updated is a candidate workaround; behavior with a fresh Remote-created task remains untested.

Environment:

Desktop 26.901.51231, build 8109
Bundled app-server 0.153.4
macOS 26.4.1
ChatGPT iOS Remote → the same Mac → an existing ordinary local project, without a worktree
Project sidebar sorting: Manual order

Observed sequence today:

Start a task from iOS Remote. It runs normally and remains available on the phone, but is absent from the Mac sidebar.
Ask the agent to pin it using the built-in sidebar tool. The tool reports success, the task-list tool reports it first in Pinned, and its ID is saved in the app's local pin state. It still does not appear in the Mac UI.
Ask the agent to open that task directly in the desktop window. The conversation opens, and the saved pin now becomes visible. Desktop logs show successful thread/read and thread/resume requests.
Unpin it in the Mac UI. It appears under the correct project briefly, then disappears again. The trigger and delay for that disappearance have not yet been isolated.
Find it using the desktop's Search chats and select it. The project list extends to reveal the task. This provides a user-operated access route without asking an agent.

The task remains unarchived in local state with its history intact and the correct project cwd. The built-in task-list tool groups it under the correct project even when the visible sidebar omits it. It has source=vscode, thread_source=NULL, and is absent from the saved per-project manual order. As in my earlier report, older visible Remote tasks also have thread_source=NULL, so that field alone does not establish the cause. No SQLite, rollout, or app-state files were manually edited.

A subsequent read-only check also found this task in local_thread_catalog with missing_candidate=0. The local catalog had initial_build_complete=1 and 475 rows. I have not established whether that catalog entry existed before the direct-open operation.

The installed desktop code loads saved manual-order IDs before unlisted tasks. New desktop-created tasks are prepended to that order, whereas this Remote-created task was absent from it. Combined with the search-and-reveal result, this strongly suggests inconsistent initial placement of Remote-created tasks in Manual order. It does not establish that all reports on this issue have the same cause.

New Remote tasks should receive the same initial placement as new desktop-created tasks, including in Manual order. Requiring users to search for each new task and expand the list makes completed Remote work easy to miss. Please compare initial placement for desktop-created and Remote-created tasks, including after opening and unpinning.

Дополнительное наблюдение от 21 сентября 2026 года: задача, запущенная с телефона через ChatGPT Remote Control, не видна пользователю в списке задач Codex на подключённом Mac, хотя локальные средства чтения и перечисления задач находят её.

Окружение

ChatGPT/Codex Desktop: 26.915.31945, build 9922 (версия прочитана из установленного app bundle).
Встроенный CLI/app-server: 0.155.0-alpha.9.2.
macOS: 26.6.2, build 25G83; uname -mprs: Darwin 25.6.0 arm64 arm.
Сценарий: ChatGPT на телефоне → Remote Control → этот Mac → существующий локальный проект.
Сохранённый cwd задачи совпадает с существующим корнем проекта, а не с временным Codex worktree.
Версия мобильного клиента и ОС телефона в этой диагностике не зафиксированы.

Наблюдавшаяся последовательность

Пользователь запустил новую задачу с телефона через Remote Control.
Задача выполнилась на Mac; сохранённый turn имеет статус completed.
Вернувшись к Codex на Mac, пользователь не смог найти эту задачу в интерфейсе.
Прямой вызов read_thread по известному ID успешно вернул историю; статус задачи — idle.
list_threads также возвращает задачу с hostId=local и правильным проектом. В полном списке архивных задач её нет.

Проверенные локальные метаданные

Read-only проверка state_5.sqlite.threads:

archived = 0
source = vscode
thread_source = user
originator = Codex Desktop
model_provider = openai
history_mode = paginated
name = NULL
project_id = NULL
thread_section_id = NULL
cwd = <существующий корень выбранного проекта>

В сохранённом Desktop state отсутствует явная запись этой задачи в thread-project-assignments. При этом сервис перечисления задач определяет правильный проект. У задачи нет сгенерированного названия; в списке сервиса используется исходный запрос.

Сохранённые настройки боковой панели во время диагностики:

{"mode":"project","chatSortMode":"priority","projectSortMode":"manual"}

В отличие от ряда предыдущих сообщений здесь, у данного сеанса thread_source=user уже установлен. Поэтому объяснять именно этот случай только thread_source=NULL было бы неверно. Причина на уровне отображения/каталога/сортировки пока не установлена.

Границы проверки и ожидаемое поведение

Зафиксирован один случай. Исчезновение из интерфейса сообщено пользователем; чтение истории, перечисление задач и метаданные проверены локально. Переключение на хронологическую сортировку, раскрытие полного списка проекта, перезапуск приложения и открытие по deep link в этом случае не проверялись. Поэтому это сообщение не доказывает, что задача полностью исключена из проекта или что перечисленные способы не помогают.

Ожидается, что новая задача, созданная через мобильный Remote Control, будет доступна в соответствующем списке задач Desktop без необходимости сначала узнавать её ID. Просьба проверить этот сценарий также для history_mode=paginated, корректного thread_source=user и указанного режима сортировки.

Navigation Menu

Repository navigation

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

Summary

Environment

Steps to Reproduce

Expected Behavior

Actual Behavior

Local Evidence

Related Issues

Notes

Environment

User-visible behavior

Local state before repair

Important additional observation

Why this may be useful

Environment

Reproduction and evidence

Expected behavior

Environment

User-visible behavior

Sanitized host-side evidence before repair

Repair/backfill observation

Expected product behavior

Environment

Current reproduction

Before/after boundary

Likely regression

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Steps to Reproduce

Expected Behavior

Actual Behavior

Local Evidence

Related Issues

Notes

Activity

github-actions commented on May 19, 2026

rubensolid commented on May 19, 2026

652036 commented on Jun 19, 2026

Environment

User-visible behavior

Local state before repair

Important additional observation

Why this may be useful

andybergon commented on Jul 8, 2026

mychox68 commented on Jul 11, 2026

Environment

Reproduction and evidence

Expected behavior

simpsonkorea commented on Jul 13, 2026

alexanderxcmo commented on Jul 22, 2026

gjxgjxgjxgjx commented on Aug 3, 2026

Environment

User-visible behavior

Sanitized host-side evidence before repair

Repair/backfill observation

Expected product behavior

milobird commented on Aug 7, 2026

Environment

Current reproduction

Before/after boundary

Likely regression

markerdmann commented on Aug 13, 2026

markerdmann commented on Aug 13, 2026

skyerus commented on Aug 17, 2026

prcris commented on Aug 21, 2026

theonegri commented on Aug 28, 2026

milobird commented on Sep 7, 2026

Nurik7 commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions