Skip to content

[Remote Control][Android/Windows] Remote loads stale Codex session state instead of latest progress #46084

Open
Open
[Remote Control][Android/Windows] Remote loads stale Codex session state instead of latest progress#46084
Labels
bugSomething isn't workingremotesessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

Description

@youngbumkim80
youngbumkim80
opened on Sep 17, 2026

What issue are you seeing?

Since September 16, 2026, Codex Remote Control repeatedly fails to synchronize the latest state of an active Codex session.

When connecting remotely from the ChatGPT Android app to Codex work running on the Windows host, Remote Control loads a significantly older state of the conversation/work and then remains on that stale state instead of updating to the latest progress.

The Codex work on the host may continue, but the remote client does not reflect the current session state. This has been occurring repeatedly since yesterday and makes remote monitoring/control unreliable.

This appears to be a session/thread state synchronization or stale-state/cache problem rather than simply a one-time connection failure.

Steps to reproduce

  1. Run an active Codex development session on the Windows host and continue working so the session accumulates new progress/messages.
  2. Connect to that session remotely using ChatGPT/Codex Remote Control on Android.
  3. Open the active session.
  4. Observe that Remote Control may load a much older portion/state of the session rather than the latest state.
  5. Wait for synchronization/refresh.
  6. The remote view remains stale and does not catch up to the latest host-side progress.
  7. Repeating the connection has reproduced the issue since September 16, 2026.

Expected behavior

Remote Control should synchronize to the authoritative latest state of the selected active Codex session and continue receiving subsequent progress/messages from the host.

If synchronization cannot complete, the client should surface an explicit sync/reconnect error rather than silently presenting an old state as current.

Actual behavior

A significantly older session/work state is loaded and remains displayed without catching up to current host-side progress.

Impact

High. Long-running Codex development work cannot be reliably monitored or controlled remotely because the remote UI may silently display stale state.

Environment

  • Remote client: ChatGPT Android app / Codex Remote Control
  • Host: Windows Codex environment
  • Subscription: ChatGPT Pro
  • First repeatedly observed: September 16, 2026
  • Still occurring: September 17, 2026

Additional context

The same user has previously experienced Remote Control connection instability, but this report is specifically about a different symptom: the connection can present session content while failing to load/synchronize the latest state.

Potential areas to inspect include remote thread/session authoritative-state selection, pagination/cursor handling, stale cache invalidation, reconnect replay/resume boundaries, and host-to-mobile incremental update subscription.

No private repository names, account identifiers, or project content are included in this public report.

Activity

  1. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    remote
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Sep 17, 2026

  2. github-actions commented on Sep 17, 2026

    @github-actions
    github-actionsbot
    on Sep 17, 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. youngbumkim80 commented on Sep 17, 2026

    @youngbumkim80
    youngbumkim80
    on Sep 17, 2026 via email
    Author

  4. youngbumkim80 commented on Sep 17, 2026

    @youngbumkim80
    youngbumkim80
    on Sep 17, 2026 – with ChatGPT Codex Connector
    Author

    Update — repeated apparent execution stalls (Sep 17, 2026)

    There is an additional symptom occurring alongside the stale Remote Control state described in the original report.

    While controlling the active Codex session remotely, Codex repeatedly appears to begin executing the requested work, but then stops making visible progress and remains idle/stuck. If another instruction is sent, it appears to resume/start working again for a short period, but then stops again. This cycle can repeat:

    1. Send an instruction through Remote Control.
    2. Codex appears to start working.
    3. Progress/output stops and remains stuck with no clear completion or actionable error.
    4. Send another instruction.
    5. Codex appears to work again briefly.
    6. Progress stops again.

    This is not normal long-running-task behavior from the user's perspective because repeated additional prompts temporarily cause apparent progress to resume.

    It is currently unclear whether:

    • the underlying Codex turn/tool execution is actually stalling;
    • the host continues executing but Remote Control stops receiving progress/completion events; or
    • the remote session loses its incremental event subscription / resume cursor and therefore presents an apparently stalled turn.

    Because this started in the same period as the stale-session-state problem, these symptoms may share a synchronization/reconnect/event-delivery cause, but that relationship is not confirmed.

    Expected behavior

    An active turn should either continue through completion, explicitly report that it is waiting for user input/approval, or fail with an actionable error. Remote Control should continue receiving current progress and completion events without requiring repeated prompts to make the session appear active again.

    Impact

    This makes long-running development work unreliable: the user cannot tell whether Codex is genuinely executing, stalled on the host, or merely invisible/stale on Remote Control. Repeatedly prompting the agent risks disrupting the intended work sequence.

    Please consider inspecting host-side turn state versus Remote Control event delivery at the point where the remote UI stops advancing, including reconnect/resume cursors, incremental event subscriptions, turn completion delivery, and stale-state/cache invalidation.

  5. youngbumkim80 commented on Sep 17, 2026

    @youngbumkim80
    youngbumkim80
    on Sep 17, 2026 – with ChatGPT Codex Connector
    Author

    Additional regression observed on September 17, 2026: parallel/multi-agent execution and premature stalls

    Adding another symptom observed today in the same Windows Codex workflow. This was not occurring yesterday: parallel work was functioning normally on September 16, but behavior regressed on September 17.

    New symptoms

    1. Parallel/multi-agent work no longer behaves normally. Tasks that previously executed concurrently are no longer progressing in parallel as expected.
    2. Active work stops mid-task without completing. Codex may appear to begin processing/work, make some progress, and then simply stop while the requested task is still incomplete.
    3. Re-prompting only temporarily restores progress. When instructed again to continue, Codex may resume briefly and then stall again before completion.
    4. The regression is occurring alongside the previously reported Remote Control stale-session/synchronization problem.

    Expected behavior

    • Independent work items/subagents should continue to execute concurrently when parallel execution is requested/available.
    • A running task should continue until completion, a genuine blocking condition, user interruption, or an explicit surfaced error.
    • If an agent/subagent cannot continue, Codex should expose the reason instead of silently becoming idle.

    Actual behavior

    Parallel execution appears degraded or unavailable, and long-running work can silently stop partway through. Reissuing the instruction may cause only short-lived progress before another stall.

    Regression timing

    • September 16, 2026: parallel execution was working normally in this workflow.
    • September 17, 2026: parallel execution degradation and repeated premature task stalls observed.

    Possible areas to investigate

    Given the concurrent stale-session symptom, please consider whether these may share a state/lifecycle problem involving multi-agent scheduling, worker/subagent slot reclamation, thread/session state synchronization, event delivery/subscription, resume cursors, or context/compaction lifecycle.

    This comment reports observed behavior only; it does not claim those components are the confirmed root cause.

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

    bugSomething isn't workingremotesessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions