Skip to content

Paginated history projector rejects legacy duration objects with invalid type: map, expected f64 #41276

Open
Open
Paginated history projector rejects legacy duration objects with invalid type: map, expected f64#41276
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't working

Description

@cxy7988
cxy7988
opened on Aug 28, 2026

What version of Codex is running?

  • Affected rollouts were written by Codex Desktop / CLI 0.146.1
  • The incompatibility was observed after opening the same paginated threads with a newer Desktop app-server (0.149.1)
  • Current installed CLI used for diagnostics: codex-cli 0.150.1

What platform is your computer?

Ubuntu 22.04.5 LTS, Linux 6.8.0, x86_64.

What issue are you seeing?

Long-running local conversations created by an older Codex process disappear completely or become truncated in the Desktop GUI even though the durable rollout JSONL still contains the full transcript.

The paginated history projector repeatedly logs:

skipping rejected rollout line while projecting "<redacted rollout path>":
invalid type: map, expected f64 at line 1 column <varies>

The rejected records contain command-execution duration values serialized by the older writer as a Rust-style duration object:

"duration":{"secs":0,"nanos":137321817}

The newer projector appears to deserialize the same field as a floating-point number, equivalent to:

"duration":0.137321817

Because projection stops/rejects these otherwise valid records, the GUI does not show conversation turns that are still present on disk. This can look like chat history loss even though the source rollout is intact.

In one sanitized local repair batch, 11 rollout files contained 723 values in the legacy {"secs": ..., "nanos": ...} representation. The affected thread metadata used history_mode = "paginated".

What steps can reproduce the bug?

  1. Use Codex Desktop / CLI 0.146.1 to create or continue a paginated conversation that runs local commands.
  2. Ensure the rollout contains a completed command item whose duration is serialized as: 
    {"secs":3,"nanos":72761183}
  3. Upgrade to a newer Codex Desktop/app-server version whose history projection schema expects duration to be an f64.
  4. Reopen the old conversation or trigger history projection.
  5. Observe repeated invalid type: map, expected f64 errors.
  6. Observe that the GUI history is missing or stops before the rejected records even though the rollout JSONL remains complete.

What is the expected behavior?

Paginated history projection should remain backward compatible with rollout records written by supported older Codex versions.

The duration deserializer should accept both:

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

and:

3.072761183

Alternatively, a nonessential duration field should be normalized or omitted without rejecting the complete history item or preventing later turns from appearing.

What is the actual behavior?

The projector rejects affected rollout lines with:

invalid type: map, expected f64

The source transcript remains on disk, but the Desktop conversation pane does not materialize it correctly.

Local validation and workaround

Before repair, the rollout files and SQLite databases were backed up. The local workaround was:

  1. Stop old writers.
  2. Convert each duration map using: 
    seconds = secs + nanos / 1_000_000_000
  3. Reset/rebuild the affected paginated history projections.
  4. Restart the Desktop app-server.

After conversion, the conversations became visible again.

Post-repair validation:

PRAGMA integrity_check: ok
projected turns: 930
projected items: 9374
invalid item_json rows: 0

This indicates that the durable conversation data and SQLite structure were healthy; the incompatible duration representation was the projection blocker.

Suggested fix

  • Use a backward-compatible/untagged duration deserializer accepting both numeric seconds and {secs, nanos}.
  • Normalize legacy duration values during projection without rewriting the source rollout.
  • Continue projecting when a nonessential telemetry/timing field is incompatible.
  • Add a regression fixture containing a 0.146.1 command-execution record.
  • Consider a supported history projection repair/rebuild command so users do not need to edit SQLite or rollout JSONL manually.

Related issues

This report does not include the original database or rollout files because they contain private conversation and command output. Thread IDs, local usernames, absolute paths, request IDs, and conversation text have been removed.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    on Aug 28, 2026

  2. github-actions commented on Aug 28, 2026

    @github-actions
    github-actionsbot
    on Aug 28, 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. UtopistList commented on Aug 31, 2026

    @UtopistList
    UtopistList
    on Aug 31, 2026

    Independent reproduction on a Linux Remote Control host.

    Environment

    • Host app-server / Codex CLI: 0.146.0
    • Codex Desktop client build: 26.825.51511
    • Linux x86_64
    • First-party app-server daemon with Remote Control enabled over its private Unix socket

    Observed behavior
    A long-running task continues executing and appending to its canonical rollout after the controlling laptop disconnects, but Codex Desktop and mobile both rehydrate only an early prefix of the same task. The task remains reported as active.

    This is apparent history loss, not actual rollout loss.

    The app-server repeatedly logs:

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

    followed by:

    thread history projection ... expected ordinal 18, got 19

    The first rejected completed command item contains:

    "duration":{"secs":0,"nanos":15504}

    A streaming validation of the canonical JSONL found valid JSON and a strictly contiguous ordinal sequence. Meanwhile, thread_history_1.sqlite remained at next_rollout_ordinal = 18, and cross-device thread/read returned only the initial user message and first assistant update. The rollout continued growing after the laptop disconnected.

    The identical projector warning appears across multiple command-bearing tasks on this host beginning on 2026-08-22. Earlier phone/Desktop continuation tests had passed, indicating a regression across the history-format/update boundary rather than a pairing or service-management failure.

    Expected behavior

    • Paginated history projection must accept both numeric seconds and the legacy {secs,nanos} duration representation.
    • A nonessential timing field must not make the remaining durable transcript inaccessible.
    • When projection fails or its cursor becomes inconsistent, Codex should rebuild automatically from the canonical rollout or provide a supported, backup-safe codex history repair command.
    • Server/client version skew must not silently truncate Remote Control history.

    No live rollout or SQLite data has been rewritten. The original state is preserved for an official backward-compatible fix or supported repair path. (reported by Chat GPT)

  4. Chen-qwq commented on Sep 7, 2026

    @Chen-qwq
    Chen-qwq
    on Sep 7, 2026

    Independent Windows repro, plus a successful local reindex test:

    • Environment: Windows 11 (10.0.26200), Codex Desktop MSIX 26.901.6511.0, bundled app-server/CLI 0.146.0-alpha.3.1.
    • Symptom: after reopening a task, the UI shows only the first turn. I have a screenshot confirming the UI symptom, but am not attaching it because the sidebar contains private task/project names.
    • Two affected paginated threads were stuck at next_rollout_ordinal = 17, with only 1 projected turn and 4 projected items, even though the original rollout JSONL files were complete. The SQLite databases passed PRAGMA quick_check.
    • In one controlled affected thread, the unchanged source rollout contained 724 valid JSONL records. The old projector repeatedly logged invalid type: map, expected f64 and then expected ordinal 17, got 18.
    • Blindly rewriting legacy duration objects to numbers is not a safe workaround: the resume path and history projection path currently expect incompatible duration representations. I rolled that experiment back completely.
    • After backing up both SQLite databases and the original rollout, I deleted only that test thread's projection rows and ran the official stable @openai/codex@0.153.4 app-server once against the unchanged rollout. It rebuilt the projection to ordinal 724: 15 turns and 245 items, with PRAGMA quick_check = ok.
    • After stopping 0.153.4, the Desktop-bundled 0.146.0-alpha.3.1 app-server could read all 15 rebuilt turns via thread/turns/list. The original rollout SHA-256 remained unchanged, and I restored the thread's original archived state.

    This strongly suggests that the skip-and-advance behavior from #42369 / commit 095ac4f fixes the stalled projection when used to rebuild it, but the current Windows Desktop bundle still ships the older projector and does not automatically repair already-stalled rows.

    Could Desktop bundle the newer projector and/or expose a supported per-thread reindex/repair action? This is the same visible symptom as #42662.

  5. jhaspinelli17-web commented on Sep 10, 2026

    @jhaspinelli17-web
    jhaspinelli17-web
    on Sep 10, 2026

    I can reproduce this on Windows 11 build 26200 with the Microsoft Store Codex app 26.903.9818.0 and bundled codex-cli 0.145.0.

    Additional trigger/context in this case:

    • The user switched ChatGPT accounts in the Windows app, then switched back.
    • An existing local task opened with a blank transcript even though its rollout JSONL remained intact and the native read_thread API still returned stored messages.
    • Creating a completely new local task did not provide a durable workaround. After the new task began using tools, its transcript also became blank.
    • The original task used paginated history. The replacement task reported page.hasMore: false, so the blank transcript is not limited to reopening a long paginated task.

    Both affected rollouts contain duration objects in the form described in this issue. A read-only scan found:

    original task: 213 rollout lines containing duration objects
new replacement task: 65 rollout lines containing duration objects

    Example from the newly created task (identifiers and paths removed):

    "item": {
  "type": "CommandExecution",
  "status": "completed",
  "exit_code": 0,
  "duration": {"secs": 0, "nanos": 825830500}
}

    The local log repeatedly emits the exact errors below for both the old task and the newly created task:

    skipping rejected rollout line while projecting "<redacted rollout path>": invalid type: map, expected f64 at line 1 column <varies>

failed to project durable rollout for <redacted thread id>: thread-store internal error: thread history projection for <redacted thread id> expected ordinal 16, got 17

    Observable impact: the sidebar entry and active task continue to exist, the model can keep working, and read_thread can retrieve the user/assistant items, but the Windows app transcript pane is blank. Restarting the app and forcing navigation to the task did not restore rendering.

    No transcript or database is attached because it contains private project content. A local backup was made before further troubleshooting.

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 appapp-serverIssues involving app server protocol or interfacesbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions