Skip to content

Android Remote chats started on a Mac host do not appear in desktop app history #37385

Open
Open
Android Remote chats started on a Mac host do not appear in desktop app history#37385
Labels
appIssues related to the Codex desktop appbugSomething isn't workingremotesessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@bennettroller
bennettroller
opened on Aug 7, 2026

Android Remote chats started on a Mac host do not appear in the desktop app history

Summary

Chats started from the ChatGPT Android app through Remote against a paired Mac host execute work on that host, but those chats do not appear in the ChatGPT/Codex desktop app on the same Mac afterward. This has reproduced roughly ten times while iterating on CSS changes in a saved local project.

The documented behavior says a user can start a chat from a phone on a connected host and later open the desktop app and continue that same chat. In this case, the work and the conversation appear to be persisted through different session paths, leaving the phone-created conversation undiscoverable from the desktop UI.

Environment

  • Host: Apple silicon Mac
  • macOS: 26.4.1 (25E253)
  • ChatGPT desktop bundle identifier: com.openai.codex
  • ChatGPT desktop version: 26.721.41059 (build 5848)
  • Bundled Codex CLI: 0.146.0-alpha.3.1
  • Controller: ChatGPT app on Android (exact Android app/device build not currently available)
  • Same ChatGPT account and workspace on both devices
  • Project type: saved local Git project on the Mac host

Steps to reproduce

  1. On the Mac, run the ChatGPT desktop app and enable Settings > Connections > Control this Mac.
  2. Pair an Android phone and confirm the Mac is available under Remote in the Android ChatGPT app.
  3. From Android, open the paired Mac host, select a saved local project, and start a new Codex chat.
  4. Send prompts and let the chat modify or inspect files on the Mac host.
  5. Return to the ChatGPT desktop app on that same Mac.
  6. Select the same project, use the chronological chat filter, and check archived chats.

Expected behavior

The Android-started remote chat appears in the desktop app history for the same host/project and can be continued there.

Actual behavior

The work can run on the Mac host, but the Android-started chat is absent from the desktop app sidebar/history. Repeating the flow creates more phone-visible remote chats without making them discoverable on the desktop.

Restarting/reloading the desktop app and checking chronological and archived views does not recover the missing chats.

Diagnostic evidence

  • The desktop task/project enumeration shows the saved project and recent desktop-created chats, but no matching Android-started chats.
  • A prior attempted workaround manually ran persistent codex exec to create a second local handoff session. That new local session appeared in the desktop index, but it did not synchronize or repair the original Android-started conversation.
  • The workaround identified the boundary as the phone/API conversation not being added to the desktop-visible local Codex session index (~/.codex/session_index.jsonl).
  • This suggests a persistence/indexing mismatch between Android Remote-created chats and the host desktop history, rather than a project or application-code issue.

Frequency and impact

  • Frequency: approximately 10/10 attempts in this workflow
  • Impact: high friction and loss of conversational continuity when moving from phone testing back to the Mac; repeated work and troubleshooting were required.

Privacy note

Private project URLs, credentials, and full logs are intentionally omitted. Sanitized logs/session IDs can be supplied privately if requested.

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 Aug 7, 2026

  2. github-actions commented on Aug 7, 2026

    @github-actions
    github-actionsBot
    on Aug 7, 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. AideYu commented on Aug 20, 2026

    @AideYu
    AideYu
    on Aug 20, 2026

    Additional reproduction: Android Remote chat disappears after backgrounding the ChatGPT app

    I can reproduce a closely related failure with ChatGPT for Android controlling a Mac mini through Remote.

    Steps to reproduce

    1. Open ChatGPT on an Android phone.
    2. Enter Remote and connect to my paired Mac mini.
    3. Start a new chat/session through the remote interface.
    4. Send a request. The session initially works normally and enters the expected in-progress execution flow.
    5. Exit the ChatGPT app, minimize it, or switch to another Android app.
    6. Wait for a while, then reopen ChatGPT and return to the Remote interface.

    Actual behavior

    The newly created remote chat/session has disappeared from the Android Remote conversation list. Refreshing the Remote view does not bring it back. The session is not visible for continuing, even though it was active and progressing normally before the ChatGPT app was backgrounded.

    This appears to be triggered specifically by backgrounding or leaving the Android app after creating a new Remote chat. It is not an intentional archive or deletion action.

    Expected behavior

    A Remote chat created from Android should remain visible and resumable after the ChatGPT app is minimized, closed, or reopened, unless the user explicitly archives or deletes it.

    Environment

    • Controller: ChatGPT app on Android
    • Host: Mac mini
    • Feature: ChatGPT Android Remote controlling the Mac host
    • Account/workspace: same account and workspace on both devices

    This may be a mobile-side session persistence/list-indexing problem related to the Android app lifecycle. The session is initially usable, but after the app is backgrounded it is no longer discoverable in the Remote UI.

  4. Dory123456 commented on Aug 21, 2026

    @Dory123456
    Dory123456
    on Aug 21, 2026

    Additional reproduction: iPhone Remote sessions exist locally but are not discoverable in the Mac desktop sidebar

    I can reproduce the same class of issue using the ChatGPT/Codex app on iPhone to control a paired Mac.

    Environment

    • Host: Apple silicon Mac
    • macOS: 15.5 (24F74)
    • ChatGPT/Codex desktop: 26.814.41407 (build 6720)
    • Bundled Codex CLI recorded in the sessions: 0.148.0-alpha.15
    • Controller: ChatGPT app on iPhone (exact iOS app build not captured)
    • Same ChatGPT account and same Mac host

    What happened

    1. A travel-planning task was originally created in one local project on the Mac.
    2. The user later continued the work from the iPhone Remote interface.
    3. The iPhone-created follow-up work ran on the Mac and successfully modified the same HTML artifact.
    4. However, the follow-up conversation did not appear as a continuation of the original desktop task.
    5. Local diagnostics showed that the phone activity had created two separate Codex sessions/tasks under a different working-directory association.
    6. Both sessions were present in ~/.codex/sessions/... and had entries in ~/.codex/session_index.jsonl, but they were not discoverable from the expected desktop project/sidebar view.
    7. When the exact latest thread ID was used through task navigation, the desktop app could open it. This suggests that the conversation data was not lost; the failure is in desktop discovery, project/workspace association, or indexing.

    Frequency

    Observed for 2/2 iPhone-created follow-up tasks in this workflow.

    Expected behavior

    A task started or continued through iPhone Remote should either:

    • remain attached to the original task when the user is continuing it, or
    • appear as a clearly visible new task in the Mac desktop history for the selected host/project.

    It should not require examining local session files or knowing the thread ID to recover it.

    Additional indexing observation

    The original task's session_index.jsonl updated_at value remained at its initial creation time even though the underlying JSONL session continued for many more hours. This can also cause an active task to be sorted or displayed as stale.

    Private project paths, public preview URLs, full logs, and thread IDs are intentionally omitted. Sanitized timestamps or logs can be supplied privately if useful.

    Thanks to the user who carefully reconstructed the mobile/desktop timeline and provided the reproducible evidence for this report.

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