[Bug] Remote SSH history projection rejects legacy duration objects

What version of the Codex App are you using (From “About Codex” dialog)?

Windows MSIX package: OpenAI.Codex_26.825.6671.0_x64__2p2nqsd0c76g0

What subscription do you have?

Not disclosed.

What platform is your computer?

Windows 10 Pro 25H2, build 26200, x64.

The symptom reproduced on two separate Windows PCs using the same account and the same configured SSH remote environment.

Update: confirmed root cause

This is not a renderer-only failure.

For one affected SSH-remote task, the durable rollout JSONL was intact: 2,632 contiguous records containing 22 completed turns. However, its paginated history projection had stopped at record ordinal 17, so Desktop could retrieve only stale/incomplete materialized history after reopening the task.

The remote app-server logged this projection error:

skipping rejected rollout line while projecting ...:
invalid type: map, expected f64

The rollout contained 384 legacy command-duration values serialized as:

"duration":{"secs":3,"nanos":72761183}

The current projector expected numeric seconds instead. When it encountered the legacy object, it rejected the record and stopped projecting later history items. This made the Desktop conversation pane look blank or incomplete even though the source transcript still existed on the remote host.

This matches #41276, which reports the same legacy-duration deserialization failure in the paginated history projector.

What issue are you seeing?

Persisted Codex task histories on an SSH remote environment are visible in the Desktop sidebar, but reopening an affected task after a Desktop restart can show an empty or incomplete conversation pane.

The underlying task data remains present, but the app-server's paginated history materialization can stop before later turns. Because the history is stored on the shared remote host, opening the same task from a second Windows PC reproduces the same symptom.

What steps can reproduce the bug?

1. Create or continue a paginated task with an older Codex writer that stores a command duration as {"secs": ..., "nanos": ...}.
2. Open that task with a newer Desktop/app-server whose paginated projector expects duration to be an f64.
3. Reopen the task or trigger history projection.
4. Observe invalid type: map, expected f64 in the projector log.
5. Observe that the durable rollout remains intact while the Desktop history is blank, truncated, or stale.

What is the expected behavior?

Paginated history projection must remain backward compatible with records written by supported older Codex versions. It should accept both numeric duration seconds and the legacy {secs, nanos} form, or normalize/ignore the nonessential timing field without preventing the affected item and later turns from appearing.

Validation of the affected task

Before any repair, the rollout and SQLite projection database were backed up.

After converting only the 384 legacy duration objects to numeric seconds and rebuilding the affected projection:

• the projection advanced from ordinal 17 to the end of the 2,632-record rollout;
• thread/resume returned all 22 turns;
• the task's history API again paged the newest completed turns;
• SQLite integrity check returned ok.

This confirms that the durable transcript and database structure were healthy; the incompatible duration representation was the projection blocker.

Additional information

• The confirmed sample was reproduced with and without v2rayA/proxy routing. The proxy was not causal.
• No remote hostname, task title, task ID, project path, or transcript content is included for privacy.
• Please treat this as a Windows Desktop + remote SSH reproduction of #41276. If appropriate, it can be marked as a duplicate while retaining the remote-environment scope.

Start with the paginated history projector and the related failure described in #41276, then reproduce deserialization of both numeric durations and the legacy {secs, nanos} object. Done means projection continues past legacy records, preserves later turns, and the history API returns the complete task history.