Skip to content

[Remote/mobile] Idle projectless task disappears from Recent Tasks after backing out; pin ignored #33396

Open
Open
[Remote/mobile] Idle projectless task disappears from Recent Tasks after backing out; pin ignored#33396
Labels
appIssues related to the Codex desktop appbugSomething isn't workingremotesessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@Mburdo
Mburdo
opened on Jul 15, 2026

What version of the Codex App are you using?

  • Codex Desktop for macOS: 26.707.72221 (build 5307)
  • Bundle ID: com.openai.codex
  • Codex CLI: 0.144.4
  • Mobile client: connected through Codex Remote; exact phone OS/client build was not captured

What subscription do you have?

Not included in this public report.

What platform is your computer?

macOS 15.7.4 (build 24G517) on the paired host.

What issue are you seeing?

A real task on the paired Mac repeatedly appears in Codex Remote on a phone while it is active or immediately after it is refreshed, then disappears from the phone's Recent Tasks list as soon as the user backs out of the chat and the task is idle.

The task is not deleted. Immediately after it disappears on the phone, the paired host's thread inventory still returns it with the correct title, working directory, and idle status.

Pinning the task returned success (pinned: true) but did not keep it visible in the phone's task list.

The affected thread:

  • has cwd ~/Desktop/aiw landing page
  • is returned without a projectId
  • sits under a saved ~/Desktop parent project
  • does not have its exact cwd registered as a separate saved project

This makes an intact local project look deleted and prevents the user from reliably returning to the task from a phone. Activity temporarily restores visibility, so the behavior can look like intermittent sync.

Thread and host identifiers are redacted from this public report but can be provided privately.

What steps can reproduce the bug?

  1. Start or open a task on a paired Mac whose exact cwd is not registered as its own saved project.
  2. Open Codex Remote on a phone.
  3. While the task is active, or immediately after sending it a follow-up, observe that it appears in Recent Tasks.
  4. Allow the task to become idle.
  5. Open the task on the phone, then back out to Recent Tasks.
  6. Observe that it immediately disappears.
  7. Query the paired host's thread inventory by exact thread ID.
  8. Observe that the thread is still returned as idle with the correct cwd.
  9. Pin the thread, repeat the visible -> open -> back out sequence, and observe that it still disappears.

The cycle was reproduced more than once in the same diagnostic session on July 15, 2026.

What is the expected behavior?

  • Existing idle tasks should remain discoverable after backing out.
  • A pinned task should remain visible even if it has no projectId.
  • If project association is required, a thread under a saved parent project should either inherit a stable association or the UI should explain how to register it; it should not silently disappear.

Additional information

Confirmed observations:

  • The thread persists on the paired host after the phone stops displaying it.
  • Its status is idle when missing.
  • Its returned summary has no projectId.
  • Its exact cwd is absent from saved-project inventory, although its parent ~/Desktop is saved.
  • Pinning does not keep it in the phone list.
  • Project files remain intact; this is a discovery/visibility bug, not data loss.

Working hypothesis: the mobile Remote task-list selector filters out an idle thread whose projectId is absent, and pinned state does not override that filter. Activity temporarily places the thread into a recency/active result set; navigation causes the list to recompute and exclude it again.

Related but not identical: #22806 covers Remote mobile sidebar/pin synchronization. This report adds a deterministic disappearance-on-back-out reproduction for an idle projectless thread, with host inventory evidence that the thread still exists.

A phone screen recording and sanitized desktop log excerpts can be provided if maintainers need them.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    remote
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jul 15, 2026

  2. github-actions commented on Jul 15, 2026

    @github-actions
    github-actionsBot
    on Jul 15, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. krshtrue commented on Aug 13, 2026

    @krshtrue
    krshtrue
    on Aug 13, 2026

    Additional reproduction and workaround

    I reproduced this on a headless Linux host controlled from the ChatGPT Android app through Codex Remote. The affected conversation was created/used through Remote and behaved as follows:

    • The thread appeared in the Android Remote list while it was active.
    • I could open it and continue working normally.
    • After leaving the thread/Remote view, it disappeared from the host's Recent Tasks list.
    • Refreshing the list made it disappear again.
    • Renaming the thread did not help.
    • The transcript remained intact locally and could be read/resumed by its session ID from SSH.
    • Archive/unarchive initially made it appear briefly, but it disappeared again after leaving Remote.

    The host was running Codex CLI/app-server 0.147.0. The important host-side detail was that an existing codex app-server --remote-control --listen unix:// process had been running for days but was not managed by the Codex app-server daemon. Running codex app-server daemon bootstrap --remote-control while that process was still alive failed with:

    Error: app server is running but is not managed by codex app-server daemon

    The workaround that ultimately fixed persistence was:

    1. Inspect the running processes and identify the old codex app-server --remote-control process and its app-server daemon pid-update-loop parent.
    2. Gracefully stop those specific old processes, verifying that no old app-server remains. Do not kill unrelated processes.
    3. Start Remote through the managed daemon:
    codex remote-control start
    1. With the managed app-server running, archive and immediately unarchive the affected session to force a registry/list refresh:
    codex archive <SESSION_ID>
codex unarchive <SESSION_ID>
    1. Reconnect to the host in Android Remote and open the thread without manually refreshing the list first.

    After the app-server was running under the managed daemon and the session had been archive/unarchived, the conversation remained visible after completely leaving Remote and entering it again. The local transcript was never edited or deleted.

    This suggests two interacting issues: Remote list persistence can drop an otherwise valid idle thread, and a stale/unmanaged app-server process can prevent the normal daemon/Remote registry from being refreshed. The workaround may be version-dependent, but it resolved the reproduction for me.

  4. NathanR-85 commented on Aug 14, 2026

    @NathanR-85
    NathanR-85
    on Aug 14, 2026 – with ChatGPT Codex Connector

    Additional macOS Remote reproduction on Codex Desktop 26.803.61601 (build 6396):

    • A projectless task on a paired Mac appeared normally while active.
    • After its turn stopped and the task became idle, it disappeared from Recent Tasks/the sidebar on the controller Mac. Similar intermittent behavior has occurred on mobile.
    • Pinning did not reliably preserve visibility.
    • An exact-ID lookup on the host still returned the unarchived task with intact history.
    • Reopening and resuming that exact task worked successfully.

    This supports a visibility/indexing failure rather than data loss. The controller sidebar was using Priority sorting, which may amplify the disappearance, but a pinned task should remain discoverable regardless.

  5. Dawnlxc commented on Oct 2, 2026

    @Dawnlxc
    Dawnlxc
    on Oct 2, 2026

    Additional Mac-to-Mac Remote Control reproduction, reported repeatedly on October 2–3, 2026.

    Environment

    • Remote host: macOS, Codex desktop app 26.917.62051 (build 10789), verified on the host.
    • Controller: a separate Mac; its app build has not been verified.
    • The user had recently switched ChatGPT accounts. This is context, not a confirmed cause.

    Reproduction reported by the user

    1. Connect from the controller Mac to the remote Mac.
    2. Open an existing remote conversation through its codex:// thread link, including the Remote Control host parameter.
    3. The conversation opens successfully and becomes visible.
    4. Switch to another conversation.
    5. The first conversation immediately disappears from the controller sidebar. Reopening the same link works, but switching away repeats the problem.

    Expected
    An accessible, unarchived remote conversation should remain discoverable after switching chats. The user should not need to retain and reopen a deep link on every visit.

    Host-side checks

    • Exact-ID reads and the host thread inventory still return the conversation and its history; archived = 0.
    • The host inventory associates it with a saved project by working directory, while the stored project_id was null. This differs from assuming there is no saved project.
    • Pinning through supported app tools returned success but did not resolve the controller-side symptom. At one inspection, the legacy pinned-thread list contained the ID while the current thread section was null and the app inventory omitted it from pinned chats. The cause of this discrepancy is unknown.
    • Sidebar sorting was set to updated_at during troubleshooting without resolving the reported disappearance.
    • These checks were performed on the host. The agent could not independently inspect the controller UI, so the controller reproduction above is the user's report.

    This is a persistent discoverability failure, not evidence that the transcript was deleted. Please investigate Remote Control sidebar inclusion and project/pin state synchronization after navigation and account switching. Private thread/host identifiers, account details, transcripts, and raw logs are omitted from this public report.

    Usage reset request
    Repeated troubleshooting of this issue consumed the user's time and Codex usage. The user explicitly asks Tibo / the Codex team to consider granting a usage reset credit (reset card). Please route this request to the appropriate person and advise on a private channel for any account details needed. No exact usage loss has been measured, and this request is separate from redeeming an existing reset credit.

  6. Dawnlxc commented on Oct 2, 2026

    @Dawnlxc
    Dawnlxc
    on Oct 2, 2026

    @tibo-openai Hi Tibo — could you please take a look at the Mac-to-Mac Remote Control reproduction above?

    The remote conversation opens from its deep link, then disappears from my sidebar when I switch chats. Repeated troubleshooting, including pinning and project-association changes, has not resolved the problem from my side. It has cost time and Codex usage without restoring reliable access.

    Could you grant 3 banked Codex usage reset credits as goodwill compensation, or route this request to the person who can? This is a request for additional credits, not redemption of an existing credit. I have not measured an exact usage loss.

    Detailed reproduction and checks: #33396 (comment)

    Please let me know the appropriate private support channel for account verification. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingremotesessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions