Title: Codex Remote Control sessions appear to lose progress across Desktop and mobile even though the remote rollout remains intact
Category: Codex
Tags: bug, remote-control, app-server, desktop, mobile, session-persistence
I am reporting a high-impact Codex Remote Control persistence and synchronization regression affecting long-running tasks.
SUMMARY
A Codex task can continue executing normally on a remote Linux host after the controlling laptop is shut down or disconnected. The canonical session rollout remains intact and continues receiving new records.
However, when the same task is opened from Codex Desktop or ChatGPT mobile, both clients display only an early prefix of the conversation. The later progress appears to have disappeared, even though it still exists on the remote host.
This defeats the main purpose of Remote Control: allowing a task to continue independently of the laptop and synchronizing the same conversation across Desktop and mobile.
EXISTING GITHUB REPORT
This appears to be the same underlying defect reported in the OpenAI Codex GitHub repository as issue number 41276:
“Paginated history projector rejects legacy duration objects with invalid type: map, expected f64”
I have added an independent reproduction to that GitHub issue.
If you are experiencing the same problem, please search the OpenAI Codex GitHub repository for issue 41276, add a thumbs-up reaction, and add independent technical evidence there rather than opening a duplicate.
ENVIRONMENT
- Remote host: Linux x86_64
- Host Codex CLI and app-server: version 0.146.0
- Codex Desktop build: 26.825.51511
- First-party Codex app-server daemon
- Remote Control enabled through the private app-server Unix socket
- Both Codex Desktop and ChatGPT mobile affected
The remote host remains online continuously. The laptop does not host the actual Codex task.
EXPECTED BEHAVIOR
- Start or resume a task connected to the remote Codex host.
- Allow the task to continue working.
- Shut down or disconnect the laptop.
- The task continues running on the remote host.
- Open the same task later from ChatGPT mobile or Codex Desktop.
- Both clients display the complete, current conversation and task state.
The remote host should own the continuing task, while Desktop and mobile act as synchronized clients.
ACTUAL BEHAVIOR
The task continues working and its canonical rollout continues growing on the remote host.
But both Desktop and mobile reopen only an early version of the conversation. In the reproduced case, the cross-device task reader returned only:
- the original user message;
- the initial reasoning item; and
- the first assistant progress update.
The remote rollout contained substantial later work, including later assistant updates, commands, tool results, verification work and repository activity.
The clients were displaying the same stale projected prefix, not the actual end of the persisted task.
SERVER-SIDE EVIDENCE
The Codex app-server repeatedly logs:
skipping rejected rollout line while projecting "<redacted>.jsonl":
invalid type: map, expected f64
It subsequently reports an ordinal projection failure similar to:
thread history projection ... expected ordinal 18, got 19
The rejected command-completion records contain duration values in this form:
"duration": {
"secs": 0,
"nanos": 15504
}
The paginated-history projector appears to expect a single floating-point value instead.
A streaming validation of the canonical rollout established that:
- the rollout contains valid JSON;
- its top-level ordinals are strictly contiguous;
- the rollout continues growing after the laptop disconnects;
- the original advanced work remains on disk; and
- the derived SQLite history projection remains frozen near the beginning.
This indicates that the durable source transcript is healthy, while the derived paginated-history projection rejects records written using an incompatible duration representation.
WHY THIS APPEARS TO BE A REGRESSION
The same Remote Control installation previously passed controlled continuation tests across:
- mobile to Desktop;
- Desktop to mobile;
- a managed app-server restart; and
- reconnection to the same task, repository, desk and Git state.
Those earlier tests worked.
The projector warnings begin later and affect multiple command-bearing tasks. This suggests deterioration across a Codex history-format or client/server update boundary, rather than an original pairing, systemd, network, repository or Remote Control configuration error.
The server was deliberately pinned at Codex version 0.146.0, while Desktop and mobile clients can update independently. That version skew exposed the defect, but the persistence implementation should remain backward-compatible with its own previously written session format.
USER IMPACT
This is particularly serious for unattended or long-running work:
- Users may believe completed work has been deleted.
- Mobile and Desktop show the same stale state.
- A user may restart, duplicate or abandon a task unnecessarily.
- Restarting the server in an attempt to fix the UI could interrupt a task that is actually still running.
- Long-running remote work can no longer be trusted to reappear correctly on another device.
- The canonical data may be safe, but it is effectively inaccessible through the supported clients.
This is not merely a cosmetic scroll-position problem. The clients are receiving an incomplete materialized history.
SAFETY AND PRESERVATION
I have deliberately not:
- rewritten the live rollout;
- manually converted the duration values;
- deleted or edited the live SQLite projection;
- restarted the app-server while the affected task is active; or
- enabled an uncontrolled updater.
The original state is being preserved so that an official backward-compatible fix or supported repair command can recover it safely.
The manual normalization workaround described in GitHub issue 41276 may demonstrate the root cause, but users should not have to modify Codex’s private persistence files to recover conversations written by Codex itself.
REQUESTED FIX
I believe the robust solution needs all of the following:
-
Accept both duration representations during history projection:
{“secs”: 3, “nanos”: 72761183}
and:
3.072761183
-
Treat an incompatible, nonessential timing field as recoverable instead of rejecting the complete history item.
-
Detect a projection cursor that has stopped behind a valid canonical rollout.
-
Automatically rebuild the derived history from the canonical rollout when safe.
-
Provide a supported, backup-safe command such as:
codex history doctor
codex history repair -
Add regression coverage using real command-completion records written by older Codex releases.
-
Test Remote Control with deliberate client/server version skew.
-
Test laptop disconnect and mobile or Desktop reattachment during an in-flight command.
-
Ensure a large task is retrieved through bounded or paginated history rather than an oversized single response.
RELATED GITHUB REPORTS
The closest match is OpenAI Codex GitHub issue 41276.
Related projection-cursor behavior is reported in issue 38792.
Related in-flight disconnect behavior is reported in issue 40306.
Related Remote Control history-envelope limits are reported in issue 36423.
The first issue is the closest match to this reproduction. The others describe adjacent failure modes that should be included in recovery and acceptance testing.
QUESTIONS FOR THE CODEX TEAM
- Is a backward-compatible fix for issue 41276 planned?
- Will the fix automatically recover already-affected paginated tasks?
- If not, will OpenAI provide a supported projection-rebuild command?
- Which host app-server version should currently be used with Desktop build 26.825.51511?
- Is there a documented compatibility policy for independently updated Desktop and mobile clients and a pinned remote app-server?
- Is there a safe way to prevent version skew without allowing the native updater to restart active remote tasks?
FOR OTHER AFFECTED USERS
If your task appears to have lost progress:
- Do not immediately delete or archive it.
- Avoid modifying files under the Codex state directory.
- Check whether the remote host and app-server are still running.
- Preserve the rollout and database files.
- Record the Codex CLI or app-server version, Desktop version, timestamp and timezone.
- Search the OpenAI Codex GitHub repository for issue 41276.
- Add a thumbs-up reaction and your independent evidence there.
Please redact thread IDs, account identifiers, authentication information, repository contents, prompts and command output before posting logs publicly.
