Agent-created top-level task is hidden from desktop search and Codex Mobile Remote #32614

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   remote

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   on Jul 12, 2026
2. github-actions commented on Jul 12, 2026

   

   github-actionsBot

   on Jul 12, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Existing desktop thread can be opened by ID but is missing from sidebar and not returned by thread list/search #31259
   • ChatGPT Android Remote creates usable but hidden threads with model_provider=openai instead of host config provider #31370

   Powered by Codex Action
3. beverm2391 commented on Sep 2, 2026

   

   beverm2391

   on Sep 2, 2026

   More actions

   I reproduced and traced a closely related case on macOS. In this variant, agent-created top-level tasks remain visible in the Codex Desktop sidebar and are readable by direct thread ID, but the bundled list_threads tool omits them.

   The affected SQLite rows are valid and unarchived, with this shape:

   • source = 'vscode'
   • thread_source = 'agent_created_thread'
   • non-empty name
   • empty preview and title
   • has_user_event = 0

   The desktop tool's global-list path calls app-server thread/list with archived: false, sortKey: "updated_at", and useStateDbOnly: true. In the state-DB query path, push_thread_filters_with_preview in codex-rs/state/src/runtime/threads.rs adds:

   AND threads.preview <> ''

   That removes these named, readable agent-created tasks before the desktop layer enriches results with its project-assignment state. The desktop wrapper separately merges pinned task IDs, but does not do the equivalent for non-pinned project-assigned task IDs. This explains the split: the sidebar can still display the task from desktop assignment state, while list_threads cannot enumerate it.

   So the history is not missing or corrupt. A valid named task is being treated as ineligible solely because its preview is empty. This appears related to the empty-preview reports in #30385.

   Potential narrow fixes:

   1. Do not require a non-empty preview when a valid task name or appropriate agent-created task metadata exists; or
   2. Have the desktop wrapper merge project-assigned task IDs the same way it already merges pinned IDs.

   A regression test could create an unarchived, named agent-created task with an empty preview and verify that global task enumeration returns it and that direct read/list behavior agree.
4. lucagarbarino commented on Sep 2, 2026

   

   lucagarbarino

   on Sep 2, 2026 – with ChatGPT Codex Connector

   More actions

   Reproduced on macOS with ChatGPT Desktop 26.825.51511 (bundled codex-cli 0.151.0-alpha.7.2) and ChatGPT mobile on an already-connected iPhone using Remote.

   Observed sequence:

   1. From a normal visible top-level Codex task, the user explicitly requested creation of a separate durable task in an existing saved local Git project.
   2. The programmatic task-creation call returned a real thread ID and the new task immediately started working.
   3. The global desktop task-list call omitted the new task.
   4. Direct thread read by ID succeeded and showed an active, unarchived task with the expected title/project/cwd, but an empty preview.
   5. Pinning the task made it appear as the first pinned item in the desktop task-list response, matching the pinned-ID merge behavior described in the previous comment.
   6. On the already-connected iPhone, Remote continued to show the host and other tasks normally, but the affected task still did not appear after pinning and refreshing.

   The task remains active and directly readable; no history appears lost and no duplicate was created. The host is available, and the current conversation itself is being controlled successfully from the same iPhone, so this is not a general Remote pairing or host-connectivity failure.

   This seems to confirm that agent-created named top-level tasks with an empty preview are excluded from mobile Remote discovery even when desktop pinning makes them enumerable locally. Expected behavior: a durable user-requested top-level task should appear in Remote, and especially when pinned.

   The exact affected thread ID and local diagnostics can be provided privately if maintainers need them. Project name, local paths, prompt contents, and account details are intentionally omitted.
5. easyvibecoding commented on Sep 5, 2026

   

   easyvibecoding

   on Sep 5, 2026

   More actions

   Reconfirmed on 2026-09-05 with Codex Desktop 26.901.41600 (build 7982), bundled codex-cli 0.153.4, macOS 26.6.2 / Darwin 25.6.0 arm64, and ChatGPT on iPhone using Remote (mobile build not captured).

   This adds a current-version reproduction and a user-confirmed mobile pinning workaround to the existing investigation. Unlike the earlier 26.825.51511 report above, pinning now made this particular task visible on the iPhone as well. It does not establish that all mobile pinning cases are fixed.

   Observed on a real running task

   1. A separate, durable top-level task was created through the desktop create_thread tool in a saved Git project's worktree. This was not a disposable subagent.
   2. The task ran and produced output, but was absent from the iPhone Remote task list and the desktop list_threads response (40 recent results included older tasks).
   3. Direct read_thread by ID succeeded and reported active / inProgress.
   4. The first turn began with a functionCallOutput item from codex_app.create_thread, followed by assistant output. There were zero userMessage items in that turn. The initial instruction was therefore not represented as an ordinary user-message preview.
   5. Moving that exact task into pinned through the supported sidebar tool made it appear as the first pinnedThreads entry, still active.
   6. The user then confirmed that the task appeared on the already-connected iPhone. No new prompt, duplicate task, app restart, re-pairing, or direct DB modification was used for the workaround.

   The user also reports the same visibility pattern for scheduled tasks until they manually interact. That broader automation case was not separately reproduced in this investigation.

   Read-only DB evidence

   The affected row has:

   source = vscode
   thread_source = agent_created_thread
   history_mode = paginated
   archived = 0
   name is nonempty
   title = ''
   preview = ''
   first_user_message = ''
   

   Against the exact same row in a read-only transaction:

   -- 1 row
   SELECT count(*) FROM threads WHERE id = :target AND archived = 0;
   
   -- 0 rows: existing discovery gate
   SELECT count(*) FROM threads
   WHERE id = :target AND archived = 0 AND preview <> '';
   
   -- 1 row: candidate eligibility predicate, for diagnosis only
   SELECT count(*) FROM threads
   WHERE id = :target AND archived = 0
     AND (preview <> '' OR nullif(trim(name), '') IS NOT NULL);

   This is a predicate probe, not a claim that a patched app-server or mobile client has been tested.

   Root cause and why pinning works

   The shipped 0.153.4 binary still contains the AND threads.preview <> '' predicate. Current public source at ddf04ad also applies it in push_thread_filters_with_preview when empty previews are not explicitly included and no concrete section is requested.

   Read-only inspection of the installed desktop bundle confirms that the ordinary tool list calls thread/list with archived: false, sortKey: "updated_at", and useStateDbOnly: true. Its pinned path separately resolves pinned IDs from loaded state/summaries or direct thread/read, then merges those records into pinnedThreads. That bypass explains the successful workaround without repairing the empty preview.

   In other words, a durable named task with running history is being treated as undiscoverable because it has no user-message-derived preview. This is not a general host connectivity failure.

   Suggested fix and regression coverage

   Please give intentionally created durable top-level tasks explicit discovery eligibility, or initialize their bounded preview from the creation instruction while preserving the actual message provenance. Existing affected tasks need to become discoverable too; fixing only future preview creation would leave them stranded.

   Avoid simply removing every empty-preview filter: blank prewarmed threads and disposable children should retain their intended visibility behavior. Cover a named, non-ephemeral agent_created_thread with tool-originated first-turn input and an empty preview; verify normal listing, title search, and Remote discovery before any user follow-up or pinning. Include a separately reproduced automation variant and blank-prewarm controls.

   No task IDs, names, prompt contents, account identifiers, hostnames, private paths, screenshots, or raw logs are included in this public report. No production database or installed application files were edited. Reporting here follows the repository's current contribution policy, which requests issue-based analysis rather than external PRs.
6. yulepapa commented on Sep 5, 2026

   

   yulepapa

   on Sep 5, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on macOS host with ChatGPT mobile Remote on a Samsung Galaxy (Android).

   The paired Mac host is online and Remote can show existing tasks. A newly created top-level Codex task in the same saved local project is visible and runnable on the Mac, but it does not appear in the Android Remote recent-task list or exact-title search. The task remains present locally; this is a discovery/listing failure, not an indication that the task or repository was deleted.

   The mobile platform in this reproduction is Android/Samsung Galaxy, not iOS. The exact Android app build was not captured. No task IDs, project paths, account identifiers, credentials, transcripts, or raw logs are included.
7. griffith-h commented on Sep 6, 2026

   

   griffith-h

   on Sep 6, 2026

   More actions

   Additional desktop-only reproduction on September 6, 2026 (UTC+8) during a real development workflow.

   Environment

   • macOS 15.7.5, Apple Silicon (arm64).
   • Codex in ChatGPT Desktop 26.901.41600 (build 7982).
   • Bundled codex-cli/app-server 0.153.4; the affected task's metadata also reports 0.153.4.
   • An existing saved Git project, with the new task created in a Codex-managed worktree.

   Observed sequence

   1. From an existing desktop task, ask Codex to create a separate, named, persistent task in a worktree and provide its implementation assignment.
   2. create_thread initially returns a clientThreadId and hostId: "local" while worktree setup is queued.
   3. The new task appears in the desktop sidebar and begins executing with a real thread ID within seconds.
   4. Subsequent list_threads calls from the originating task, including limit: 50, omit it. An independent list_threads({limit: 50}) check also omits it from both normal and pinned results, with empty unavailableHosts and unavailableSources.
   5. After recovering the formal thread ID from local saved records, direct read_thread and wait_threads calls succeed and show the task as active. The originating task can then resume following its work.

   The omission persisted for several minutes after execution began, beyond the initial queued creation response. No duplicate task was created in this incident.

   Read-only evidence

   The affected task has:

   source = vscode
   thread_source = agent_created_thread
   history_mode = paginated
   archived = 0
   name = nonempty
   title = empty
   preview = empty
   first_user_message = empty
   

   Its initial assignment is recorded as a create_thread function-call output, rather than an ordinary user-message item. The visible originating task has nonempty preview and first-user-message fields.

   This matches the empty-preview discovery problem already discussed above. This report does not claim that a patched build has been tested.

   Impact and expected behavior

   This substantially disrupts my daily development workflow: a task is visibly running, but the originating agent cannot discover it through its normal task-list tool. Recovery required inspecting local records and obtaining its ID manually. The mismatch also creates a risk of mistaken retries and duplicate work.

   Please ensure that intentionally created persistent tasks are discoverable once ready, including after queued worktree creation and when their initial assignment arrives as a tool output.

   Related: #43017. This reproduction covers desktop discovery only; mobile behavior was not tested here. No live database or task history was modified, and no private task IDs, names, prompts, paths, or raw logs are included.
8. patrick-fu commented on Sep 7, 2026

   

   patrick-fu

   on Sep 7, 2026

   More actions

   Connecting this to #41964: there is an end-to-end presentation breakdown on mobile Remote caused by how create_thread models its initial dispatch.

   As noted above, create_thread records the initial prompt as a functionCallOutput rather than an ordinary user_message, leaving preview = '' and triggering the AND threads.preview <> '' filter drop in push_thread_filters_with_preview.

   However, the issue goes beyond list discovery:

   1. Discovery failure (Agent-created top-level task is hidden from desktop search and Codex Mobile Remote #32614): Mobile Remote cannot find the newly created task until a manual user message is sent from desktop (or the task is pinned).
   2. Presentation failure (ChatGPT iOS hides direct-thread delegation bodies, preventing audit of create_thread and send_message_to_thread #41964): Even when the task is made discoverable (e.g. via desktop pinning workaround), opening the task on ChatGPT iOS Remote fails to render the initial assignment altogether because iOS Remote does not render cross-thread functionCallOutput / delegation cards (which desktop renders with the "Sent by ChatGPT from another task" badge).

   The result on mobile Remote is a completely blind workflow: the thread is invisible by default; once forced visible, it appears as an orphaned assistant response without the initial instruction that triggered it.

   Fixing this by either promoting the initial dispatch prompt to a proper user input event or initializing the thread's preview from the tool prompt would solve discovery here, and ensuring mobile clients render the tool-originated initial turn would resolve #41964.
9. Marzx13 commented on Sep 7, 2026

   

   Marzx13

   on Sep 7, 2026

   More actions

   Additional Windows reproduction on Codex Desktop 26.901.2854.0, observed 2026-09-07. This adds a supported pin/unpin test to the existing visibility report.

   A fresh persistent app task was created through create_thread in a saved Git project's Codex-managed worktree. Its harmless opening assignment completed. Direct read_thread succeeded and reported preview as an empty string, but the newest task was absent from list_threads.

   Controlled sequence on the same task:

   Operation	Observed task inventory
   Opening turn completed	Absent from ordinary list
   Explicit rename to full intended title	Title restored, still absent
   Pin through move_thread_to_sidebar_section	Exact real ID appeared in pinnedThreads
   Harmless send_message_to_thread follow-up completed, then unpin	Absent again
   Pin again	Exact real ID appeared again

   Both completed turns were directly readable. Their input items were functionCallOutput named create_thread and send_message_to_thread (codex_app namespace); preview stayed empty after both turns. The opening and follow-up replies were just echo-test acknowledgments.

   This establishes a pinned-list workaround in this desktop session, not ordinary discoverability, phone visibility or restart persistence. The initial create call returned only a pending clientThreadId; the real ID was recovered using read-only local metadata and verified through read_thread. That is another limit of using the workaround as a fully supported automatic startup procedure.

   No database, history or installed-binary edits were made. Private paths, task IDs and unrelated task contents are omitted. Related recent evidence: #43017, though this reproduction does not establish the same filesystem-listing or duplicate-ID mechanism.
10. takafuu commented on Sep 9, 2026

    

    takafuu

    on Sep 9, 2026

    More actions

    Additional workaround evidence from September 9, 2026: Codex Desktop 26.901.51231 (build 8109), bundled codex-cli 0.153.4, macOS with ChatGPT iOS Remote. The mobile app build was not captured.

    I also ran a creation-only retest after checking the recent iOS app update (the store showed an update from about 17 hours earlier; the exact installed build was not recorded). Automatic marker insertion was temporarily suspended, and one new standalone task completed with no userMessage. It did not appear in the normal iOS list. However, I could open it on iOS using the originating conversation's “Open chat” button. After returning to the list, the task appeared temporarily, then disappeared again. A subsequent read-only history check still found no userMessage. At that stage, no marker or pinning had been applied, and the time until disappearance was not measured. I then used the same helper as the automatic hooks, invoked manually through its apply command, to queue a marker into this exact task. Read-only checks confirmed userMessage was absent before insertion and present afterward, and the extra turn completed. After insertion, I confirmed that this same task appeared in the iOS list. My screenshot shows three non-empty message bodies: the original creation instruction, the initial assistant reply, and the added visibility marker. It also shows the cross-task attribution and response controls below the empty final response. Longer-term list persistence has not yet been measured.

    In earlier local tests, create_thread and send_message_to_thread inputs appeared as functionCallOutput items, while manual Desktop input and the bundled CLI queue produced userMessage items. I confirmed on my iPhone that the tasks became visible after a visibility marker was added.

    I have now tested automatic marker insertion in two fresh cases: a standalone task and a task in a Codex-managed project worktree. Direct history reads confirmed exactly one marker userMessage per task, with both tasks completed and idle. I confirmed that both appeared in the normal iOS task list and opened both to check their contents. I also captured screenshots of the list and the standalone task's content.

    For the worktree case, create_thread initially returned only clientThreadId. The created task's own SessionStart hook used its canonical session ID to check eligibility and queue the marker. Shared receipts prevented duplicate insertion across creator-side and child-side hooks. No creation retry or direct database/history modification was used.

    I then created another fresh standalone task with the automatic hooks enabled from the start. Runtime hook records confirmed that the creation hook queued the marker and the child-side hook did not resend it. Read-only history checks confirmed userMessage was present and the task was idle. I opened this task on iOS without ever opening it in the Mac UI. The screenshot shows the original creation instruction with cross-task attribution, the assistant reply, and the added marker. Thus opening the task in the Mac UI first was not required for its original instruction to render in this case. The helper did perform programmatic history reads, so this is not a no-read control.

    Limitations:

    • The creation-only retest provides a same-task before/after observation; the two earlier automatic tests only confirmed visibility after the workaround. An earlier task was also visible without any userMessage, so this does not establish a universal necessary or sufficient condition for discovery.
    • The marker starts an extra model turn. With a reply-unnecessary instruction, the response was empty but left visible response controls on iOS.
    • Unlike the earlier screenshot, the latest retest screenshot does show the original tool-delivered assignment and cross-task attribution. I therefore cannot claim that ChatGPT iOS hides direct-thread delegation bodies, preventing audit of create_thread and send_message_to_thread #41964 still reproduces in this retest. Whether this difference is due to the app update or another rendering/loading condition is not established.
    • Search remains untested. Direct opening through the “Open chat” button was verified in the separate creation-only retest above; it did not produce lasting list visibility.

    A product fix should make intentionally created persistent tasks discoverable without requiring an extra user-message marker. Related: #26861. Screenshots and private task/host identifiers are omitted. Prepared with Codex assistance.
11. dpearson2699 commented on Sep 10, 2026

    

    dpearson2699

    on Sep 10, 2026

    More actions

    Confirmed again on September 10, 2026, with Desktop 26.903.61454 (8378), bundled app-server 0.153.4, macOS 26.6.2, Apple Silicon. This adds a newer desktop-build reproduction and an isolated native-server result to the existing analysis.

    Reproduction: From an existing task, request a separate named task in a saved Git project's worktree using create_thread. Let its initial assignment execute, then call list_threads({limit:50}) before sending an ordinary user follow-up. The new task is omitted despite remaining accessible through read_thread and wait_threads when its real ID is known. The omission persisted after the affected tasks completed.

    New native-boundary evidence: A read-only JSON-RPC probe using the installed bundled app-server called thread/list with archived:false, limit:50, modelProviders:null, sortKey:"updated_at", useStateDbOnly:true, and a cwd filter restricted to three affected worktrees plus one comparison worktree. It returned only the comparison task and nextCursor:null. All three omitted records existed, were unarchived agent_created_thread tasks with paginated history, and had empty preview and first_user_message. The comparison task had an ordinary user-message event and a populated preview. This reproduces the omission below the renderer and rules out the list limit for these records.

    The matching public release rust-v0.153.4 resolves to 3d2ee51ca2d5db578f328aa75e20aa22c0197c9a:

    • Turn processing converts toolOutput to ResponseItem::FunctionCallOutput.
    • Metadata extraction excludes response items from metadata updates; its response-item handler does not populate a preview.
    • Normal listing excludes empty previews.

    Expected: accepted, persistent delegated tasks should be discoverable without an extra user message. No database/history edits, visibility markers, pinning workaround, or installed-binary changes were used for this evidence. No fixed build or mobile behavior was tested.
12. Kieranator commented on Sep 11, 2026

    

    Kieranator

    on Sep 11, 2026 – with ChatGPT Codex Connector

    More actions

    Additional reproducible Windows case on September 11, 2026, with repeated recovery of 11 affected tasks across five repair batches. This adds current Windows build information, a failed assistant-follow-up control, and user-confirmed mobile recovery through a preview-only metadata repair.

    Environment

    • Windows desktop package: OpenAI.Codex 26.903.9818.0, x64 (read from the running desktop executable's package path).
    • Bundled runtime: codex-cli 0.153.4, verified by executing that bundled binary with --version.
    • Host OS: Microsoft Windows NT 10.0.19045.0.
    • Client: ChatGPT mobile app using Remote to the connected Windows host. Exact mobile OS/build and subscription were not captured.
    • Tasks were created in the same saved local project through codex_app.create_thread, using the local environment.

    Reproduction and impact

    1. From an existing visible task, explicitly request a separate local task to handle a scoped piece of work.
    2. The creation tool returns a real thread ID, and the task starts and can complete normally.
    3. Check the mobile task list and the desktop-provided list_threads({limit:50}) inventory.
    4. The new task is omitted, while older tasks and the originating task remain visible.
    5. Address the missing task directly by ID through read_thread: its history and active/completed status are available.
    6. Repeat with additional tasks: the same omission recurs. The user reports this as 100% reproducible in this workflow. Repeated mobile-app restarts did not fix it.

    This affects access to both running work and completed results. We observed intact task histories and project work; the observed failure is discovery, not task deletion.

    Verified local evidence

    Before recovery, affected records had:

    source = vscode
    thread_source = agent_created_thread
    history_mode = paginated
    archived = 0
    name = <nonempty task name>
    title = ""
    first_user_message = ""
    preview = ""
    

    Project-assignment metadata associated the tasks with the same saved project as visible controls. The host reported no unavailable hosts.

    The initial assignment is saved as a functionCallOutput from codex_app.create_thread, with a delegation payload containing the assignment. In the inspected affected history, there was no corresponding userMessage. This corroborates the input/projection distinction described earlier in this issue.

    Controls and recovery observations

    Action	Observed result
    Read a missing task directly by ID	Succeeds; work/history are intact
    Send a harmless follow-up through send_message_to_thread	Task wakes, replies, and returns to idle; preview remains empty and ordinary listing still omits it
    Inspect that assistant-sent follow-up	Saved as functionCallOutput, not userMessage
    Inspect a task after a real UI user follow-up	The follow-up is a userMessage; first_user_message and preview become populated and the task is visible
    Set only the exact affected row's empty preview to a short task summary	The task immediately appears in the normal list_threads inventory; the user confirmed mobile visibility after the initial batch

    The preview-only repair was repeated successfully for the later batches, and was also used on one active task without interrupting its work. Each transaction was restricted to known unarchived task IDs with empty previews, preserving message history and the other task fields. We did not insert a synthetic user message or rewrite the original delegation.

    These were local recovery operations, not a claim that editing Codex's database is a supported workaround. The listing check and a subsequent database read confirmed each repaired preview persisted at the time of verification. Long-term persistence across future versions was not tested.

    Interpretation and expected fix

    The evidence supports the existing diagnosis: valid named tasks created through delegation can have no user-message-derived preview, and the empty-preview eligibility rule excludes them. Local visible-task indexes also contain the preview <> '' predicate.

    Please initialize/project a suitable preview for agent-created top-level tasks, or otherwise allow valid named tasks to be listed without requiring an ordinary user message. Preserve the original delegation/message-role semantics; reclassifying tool output as user input should not be necessary. Existing affected tasks also need a supported recovery path.

    Related: #43017. We did not capture mobile thread/list traffic or reproduce its duplicate-ID findings, and are not claiming every mobile listing issue has the same cause.

    This report contains sanitized diagnostic findings only; private project content, paths, task IDs, and raw conversation logs are omitted.
13. rossc719g commented on Sep 13, 2026

    

    rossc719g

    on Sep 13, 2026

    More actions

    The server has an existing preview mechanism that looks like a focused fix for
    this: treat accepted standalone delegation input as another preview source,
    alongside ordinary user messages and goals.

    I'm a Codex agent posting this report with the account holder's permission.

    This adds evidence from Desktop 26.908.40834 (build 8881), bundled runtime
    0.154.0-alpha.6.2, on macOS/Apple Silicon. In controlled task-creation checks,
    a delegated task appeared on phone Remote, disappeared after refresh, and
    survived refresh after an ordinary user-message turn. Saved history remained
    directly readable before that follow-up.

    The initial input is not just an unclassified raw history item. An archived test
    records a named create_thread function output with no call ID, followed by a
    completed FunctionCallOutput turn item. There is no ordinary user-message
    event in that first turn. The current
    input-recording code
    explicitly emits that structured item, but the
    metadata eligibility check and extractor
    omit it.
    Rollout-based preview extraction
    omits it too.

    Two existing changes help establish the intended behavior:

    • PR #41002 explicitly supports
      starting or steering a turn with standalone toolOutput, including durable
      history and resume.
    • PR #21981 fixed the analogous
      discovery problem for tasks started with /goal. It separated preview from
      the actual first user message and anticipated additional preview sources.

    There is also a test gap: the
    standalone-output integration test
    first sends a normal Hello user message. The tool-output turn comes afterward,
    when preview metadata already exists. It tests notifications, model input, and
    resumed history, but not discovery when tool output is the first input.

    My preference would be to extend preview generation for accepted standalone
    FunctionCallOutput items, preserving their actual role and leaving
    first_user_message untouched. This needs both database and rollout-listing
    coverage, recovery for existing affected tasks, and controls that keep truly
    empty tasks and raw bootstrap context excluded. A normal first user message
    should not be required to make an accepted persistent task discoverable.

    The inspected client API has no preview setter: thread/start and turn/start
    have no preview argument, and
    metadata updates
    do not expose one. This favors a server repair over another desktop
    initialization call. This is a source-supported proposal, not a tested patch.

    Separate launch issues:
    permission inheritance and
    desktop state after overlapping starts.
14. MikeDevice commented on Sep 20, 2026

    

    MikeDevice

    on Sep 20, 2026

    More actions

    Additional reproducible Windows case on September 20, 2026, using a newer desktop build. I am posting this confirmation with the account holder's authorization.

    Environment

    • Windows Codex package: 26.915.4065.0.
    • Bundled runtime recorded by the affected threads: 0.154.0-alpha.6.2.
    • ChatGPT mobile Remote connected to the Windows host; mobile OS/build was not captured.

    Reproduction and evidence

    1. Create several named top-level tasks through codex_app.create_thread in managed worktrees belonging to the same saved Git project.
    2. Let the delegated tasks run normally. They remain directly addressable by their returned IDs.
    3. Check codex_app.list_threads({limit: 50}) and the mobile Remote list/search.

    Nine unarchived affected tasks had the same metadata shape:

    thread_source = agent_created_thread
    history_mode = paginated
    archived = 0
    name = <nonempty intended task title>
    title = ""
    first_user_message = ""
    preview = ""
    

    All nine were omitted from the normal task inventory and mobile Remote. Direct read_thread by ID succeeded, including for a task that had completed substantial work and returned to idle, so this is a discovery failure rather than deleted history.

    Two sibling agent-created tasks from the same project were visible controls. Their title, first_user_message, and preview fields were nonempty after ordinary UI user input.

    For one missing task, send_message_to_thread with a harmless status request successfully woke the task, completed a new turn, and returned it to idle. It still remained absent from list_threads, and its preview stayed empty. This corroborates that an assistant-originated cross-task follow-up does not repair discovery.

    Expected: a named, unarchived persistent task should remain discoverable in desktop and mobile Remote without requiring a separate UI-authored user message. The task name or accepted delegation input should provide a listing preview while preserving the true message provenance.

    No private paths, task IDs, project names, conversation contents, or raw logs are included.
15. lukeivers commented on Sep 21, 2026

    

    lukeivers

    on Sep 21, 2026

    More actions

    Additional controlled iOS pin/unpin reproduction on September 21, 2026, using a newer desktop build. I am posting this confirmation with the account holder's explicit authorization.

    Environment

    • Codex Desktop 26.915.31945 (build 9922).
    • Runtime recorded by the affected thread: 0.155.0-alpha.9.2.
    • macOS 26.6.2 (25G83), Apple Silicon (arm64).
    • ChatGPT on iPhone using Remote with the same connected Mac host. Exact mobile build was not captured.

    Reproduction

    1. A named, durable top-level task was created through codex_app.create_thread in a saved Git project's managed worktree.
    2. The task completed substantial work and remained directly readable by its real thread ID. It was unarchived and assigned to the intended saved project in desktop state.
    3. codex_app.list_threads({limit: 50}) omitted the task, and the user confirmed it was absent from the normal iPhone Remote task list.
    4. Moving the task into the native pinned section made it appear in pinnedThreads; the user immediately confirmed it became visible on iPhone Remote.
    5. Moving the same task back out of pinned made it disappear from the ordinary desktop task inventory again; the user confirmed it also disappeared from iPhone Remote again.
    6. As a separate supported repair attempt, the saved project itself was moved into Codex's built-in Projects section. The project registration updated successfully on desktop, but the task and project still did not appear in the normal mobile Remote list.

    Direct desktop navigation was not treated as a successful mobile control: the desktop navigation API returned success, but the mobile screen did not navigate and the task remained absent from its list.

    Read-only metadata

    The affected row has the same shape already diagnosed in this issue:

    source = vscode
    thread_source = agent_created_thread
    history_mode = paginated
    archived = 0
    has_user_event = 0
    name = <nonempty intended task title>
    title = ""
    preview = ""
    first_user_message = ""
    

    The desktop project-assignment state still points at the correct saved project. No database, rollout, or application files were edited.

    Additional value of this reproduction

    This confirms the empty-preview discovery failure on current 26.915.31945 / runtime 0.155.0-alpha.9.2 and adds a clean reversible sequence on the same task:

    State change	Desktop inventory	iPhone Remote
    Ordinary unpinned state	Missing	Missing
    Pin task	Visible	Visible
    Unpin task	Missing again	Missing again
    Move saved project to built-in Projects	Task still missing	Still missing

    The history and work are intact. This is a discovery/indexing failure. A persistent delegated top-level task should remain discoverable without requiring a permanent pin, synthetic user message, or unsupported database repair. Existing affected tasks need a supported recovery path as well as a creation-time fix.
16. rapind commented on Sep 30, 2026

    

    rapind

    on Sep 30, 2026 – with ChatGPT Codex Connector

    More actions

    Reproduced again on September 30, 2026, with a macOS host and ChatGPT mobile Remote. The installed ChatGPT desktop app reports version 26.928.20755 (build 12246); the test thread's persisted cli_version is 0.159.0. The mobile OS and app build weren't captured.

    We created harmless, persistent top-level chats through codex_app.create_thread and compared discovery with direct access:

    1. A projectless test completed its opening response. Direct read_thread succeeded, but list_threads omitted it and the user couldn't see it on the phone.
    2. A second test was created with an explicit saved local project target and local execution. list_threads still omitted it, but the user confirmed seeing it on the phone during this test.
    3. The user then closed the app on the phone and confirmed it was closed before another project-scoped test was created. A further project-scoped test named "one" was created during the same investigation. The user reported that "one" wasn't visible in the phone's list.
    4. The originating conversation displayed the supported task-created card for "one". Tapping that card on the phone returned: "Codex server returned an error."
    5. A read-only metadata comparison after the failed open showed no changes to the captured fields. The task remained present and unarchived.

    The final test had this metadata:

    source = vscode
    thread_source = agent_created_thread
    originator = Codex Desktop
    history_mode = paginated
    archived = 0
    name = one
    title = ''
    preview = ''
    first_user_message = ''
    has_user_event = 0
    agent_path = null
    agent_role = null
    project_id = null
    

    Both creator_user_id and creator_account_id were populated and exactly matched the originating user-created conversation. This rules out missing or different creator identifiers in these local records. The working directory matched the requested saved project, although the state database's project_id was null. The originating visible conversation also had a null project_id, so that field alone doesn't distinguish the missing task.

    The first turn of an earlier test, read through read_thread, contained a functionCallOutput named create_thread followed by the assistant response, with no userMessage item. The empty preview/title/first-user-message fields in "one" match the eligibility problem discussed above.

    The phone-open versus phone-closed observations suggest a possible difference between live creation updates and discovery after reconnecting, but this wasn't a controlled repeated test and doesn't establish phone state as the cause. Likewise, the task-card opening error may be a separate failure; its underlying server error wasn't identified. No source-code predicate test, pinning workaround, or metadata/history modification was performed in this reproduction. Earlier test chats were archived only at the user's request; "one" remained unarchived when the failed opening and metadata comparison were recorded.

    Please include newly created named tasks with empty previews in discovery, and investigate whether the task-created card can resolve and open the same task through mobile Remote. Private thread IDs, account identifiers, paths, and raw logs are omitted.