Activity

1. DosaoTang

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 10, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Sep 10, 2026
3. github-actions commented on Sep 10, 2026

   

   github-actionsBot

   on Sep 10, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Codex History Indexing and Side Chat Failure #44520
   • Windows app hangs and missing history: duplicate rollout ordinal persists on 26.903.9818.0 / CLI 0.153.4 #44511
   • macOS desktop task history freezes at Thursday: duplicate ordinal 12165 at stalled projection offset while Sunday transcript remains intact #43451
   • Windows 0.153.4: duplicate thread_settings_applied ordinals after resume permanently stall paginated history #44432
   • Conversation history stuck on old messages across multiple chats #43314

   Powered by Codex Action
4. RacYang commented on Sep 10, 2026

   

   RacYang

   on Sep 10, 2026

   More actions

   Additional macOS reproduction on a newer desktop build, verified read-only on 2026-09-10. This instance includes a two-ordinal rewind with different event types, rather than an exact duplicate of one idempotent event.

   Environment

   • Desktop app: 26.903.71938, build 8576 (ChatGPT.app, bundle identifier com.openai.codex).
   • Bundled codex-cli: 0.153.4.
   • macOS 26.6.2, Darwin 25.6.0 arm64 arm.
   • Affected local thread uses history_mode = paginated.

   Observed impact

   The user reported missing recent conversation history. The desktop read_thread tool, using newest-first ordering with turnLimit: 1, returns an old turn started on September 9 as inProgress, with no completion time. Later completed turns from September 10 exist in the raw rollout but are absent from the projected history. The thread metadata continues to receive current update timestamps.

   I have not independently captured the UI symptom; the stale read result, raw records, database cursor, and warning below were directly checked. I did not restart the app or modify its data during this investigation.

   Durable rollout versus projection

   At the diagnostic snapshot:

   rollout bytes                  128027894
   JSON records                   3188
   JSON syntax errors             0
   raw task_started events        26
   raw task_complete events       24
   indexed thread_turns           16
   
   next_rollout_byte_offset        94493931
   next_rollout_ordinal            2127
   bytes beyond projection cursor 33533963
   

   Zero JSON syntax errors establishes syntactic readability, not semantic validity of every record.

   The persisted cursor points exactly to this rewind:

   Byte offset	Ordinal	Event type
   94492125	2125	token_count
   94493028	2126	token_count
   94493931	2125	thread_settings_applied
   94494604	2126	thread_settings_applied
   94495279	2127	thread_settings_applied

   The most recent indexed turn starts at ordinal 2115 and remains inProgress, completed_at = NULL. Later task_started / task_complete pairs remain in the JSONL. The cursor remained at the same position across repeated read-only checks.

   The retained runtime logs contain 452 matching warnings at snapshot time:

   target=codex_thread_store::local::live_writer
   failed to project durable rollout for <thread-id>:
   thread-store internal error:
   thread history projection for <thread-id>
   expected ordinal 2127, got 2125
   

   Reproduction on this already-affected thread

   1. Read its latest turn through the desktop history tool: an older unfinished turn is returned.
   2. Read the corresponding row in thread_history_projection_state: it expects ordinal 2127 at byte 94493931.
   3. Inspect the original JSONL at that byte offset: it contains ordinal 2125, event_msg / thread_settings_applied.
   4. Inspect later raw records: later user/assistant messages and completed turns are still present.
   5. Repeat the read and inspect the cursor/logs: the projected history remains stale and the same ordinal mismatch recurs.

   The initial event that caused ordinal reuse is not established. This is an observed failure on an existing thread, not a clean-install reproduction. In particular, the records reusing 2125 and 2126 have different event types from their predecessors, so treating them as exact duplicate payloads would be an unsafe assumption.

   Please provide a supported, non-destructive per-thread recovery/reprojection path that preserves both records and later content, and make incomplete history visible instead of silently presenting an old turn as the latest.

   No original rollout, database, or cache was edited/deleted. Full transcripts, images, account details, real thread identifiers, personal paths, and project content are omitted from this public report.

   👍React with 👍1Reacted by DosaoTang

   ❤️React with ❤️1Reacted by DosaoTang
5. Timeless321 commented on Sep 11, 2026

   

   Timeless321

   on Sep 11, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows evidence: history projection stalled on ordinal mismatch (CLI 0.153.4)

   Environment: Windows; installed Codex CLI 0.153.4. Affected task: <affected-thread-id>.

   Observed behavior

   The user reports missing recent messages inside an existing Desktop task after an update/restart. Reading the latest turns through the Desktop task-reading tool returns September 7, 2026 content, although the original persisted JSONL contains messages through September 11. The issue was noticed around an update, but the timing does not establish that the update caused it. This is an additional observed instance related to this issue, not a deterministic clean-install reproduction. The Desktop build number was not independently captured; the CLI version above was checked locally.

   Two Desktop log entries, at 2026-09-11T04:33:48.016Z and 2026-09-11T04:33:49.849Z, record thread/revert failing with code -32603:

   failed to revert session: thread-store internal error: thread history projection for <affected-thread-id> expected ordinal 15825, got 15824
   

   Read-only diagnostic evidence

   • The captured source snapshot is 249,303,924 bytes, containing 45,168 physical lines / nonempty records, with zero JSON parse errors.
   • Stored projection progress is byte offset 97,319,419, with next ordinal 15,825. That offset corresponds to physical line 15,826, after 15,825 nonempty records.
   • 151,984,505 bytes remain after the stored projection offset within the snapshot.
   • A filtered local export finds 611 visible-message records after that offset, from 2026-09-07T04:23:57.335Z through 2026-09-11T04:47:16.539Z. This establishes that specific later messages persist; it does not establish complete historical losslessness or reconstruct every UI item.
   • A codex migrate-rollouts --thread <affected-thread-id> --json dry run reports already_paginated and 0 bytes processed. Migration was not applied. The installed CLI help does not expose an arbitrary transcript-import or history-rebuild command.

   Expected behavior / requested assistance

   Please investigate the ordinal mismatch and provide a supported, non-destructive way to reconcile or recover the history projection for the same existing task, using its persisted source records while preserving task identity and valid history. Recovered history should be accessible consistently in both the Desktop UI and task-reading interface.

   The exact trigger and necessary repair remain unproven. No database or original transcript was edited during diagnosis. This report intentionally excludes conversation content and local identity details; no raw transcript is attached.
6. corbett3289 commented on Sep 11, 2026

   

   corbett3289

   on Sep 11, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows reproduction / diagnostic evidence, collected 2026-09-11.

   The user reports severe desktop lag and project tasks failing to load properly, temporarily relieved by quitting/restarting the app. This workflow was reportedly working before this week; the regression has not been bisected to a particular update. Multiple local project tasks/agents and local STDIO MCP integrations are in use.

   Environment

   • Windows 11 Home, 10.0.26200 (build 26200).
   • Installed OpenAI.Codex AppX package: 26.903.9818.0 (package version, not independently checked against the About dialog).
   • Running backend binary reports: codex-cli 0.153.4.
   • Approximately 47.6 GiB physical RAM. The user reports the rest of the machine remains responsive.

   Matching history failure

   The following error continues after an app restart:

   codex_thread_store::local::live_writer
   failed to project durable rollout for <redacted-thread-id>:
   thread-store internal error:
   thread history projection for <redacted-thread-id> expected ordinal 8441, got 8440
   

   A bounded read-only inspection of the newest 3,000 log rows found 210 entries matching this ordinal error within the preceding ten minutes. This is a bounded sample, not a total log count or a measured change in error rate.

   The task-reading API also returned an older in-progress turn as the latest turn despite a newer task update timestamp. We have not performed a full canonical-rollout audit or database integrity checks, so we are not asserting transcript loss or establishing the underlying duplicate-record mechanism in this case.

   Resource observations

   Two snapshots on September 11, Eastern Daylight Time, used the same backend process (started at 08:40:58). Additional agents/tasks were opened between snapshots. Values below are summed private memory in MiB, not working set:

   Process group	08:41:58 EDT	08:51:14 EDT
   Codex backend (one process)	1,873.1 MiB	2,223.5 MiB
   Unity MCP Python processes	8 / 257.1 MiB	14 / 553.4 MiB
   Analytics + GSC lightweight adapter Python processes	20 / 151.9 MiB	28 / 210.9 MiB
   Computer-use Node processes	17 / 604.2 MiB	21 / 736.0 MiB

   Windows launcher/interpreter pairs mean the Unity counts correspond to approximately 4 then 7 MCP instances, and the adapter counts to approximately 10 then 14 adapters combined. These are process observations, not proof of concurrent tool use.

   No heavy Analytics or GSC backends were observed; their local adapters start heavy workers on demand. Reducing that MCP startup overhead has not resolved the reported desktop symptoms.

   In the previous session on September 10, the backend reached approximately 13.1 GiB private memory and consumed 10.86 CPU-seconds over a ten-second wall-clock sample. Restarting reduced backend memory but did not eliminate the ordinal error.

   Important limitation: backend memory fluctuated between samples, and opening more tasks can legitimately increase process/resource counts. These observations do NOT prove a monotonic memory leak, orphaned MCP processes, that Unity is the sole cause, or that the projection error causes the resource growth.

   Requested triage

   Please investigate the persistent history-projection failure on the current Windows backend and whether repeated projection failures or retained per-task resources can contribute to loading stalls. A supported, safe per-task history recovery mechanism would also help.

   This appears related to the history failure reported here and in #41566. No raw logs, databases, credentials, project names, local paths, or private task IDs are attached. Narrowly redacted diagnostics can be prepared if maintainers specify what is needed.
7. corbett3289 commented on Sep 13, 2026

   

   corbett3289

   on Sep 13, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up Windows diagnostics from September 13, 2026, around 09:55 EDT. This supplements our September 11 report above; the current performance symptoms may be separate from the original history-projection bug.

   User-observed impact

   The user reports tasks appearing stuck across the app, including approximately nine minutes before a short two-line response appeared. This is user-observed latency, not an instrumented end-to-end measurement, and the checks below do not fully explain that delay.

   Current measurements

   • The running backend binary now reports codex-cli 0.154.0-alpha.6.2 (previous report: 0.153.4). The desktop package version was not rechecked in this follow-up.
   • One backend process, started September 12 at 09:23:40 EDT, used 16.51 GiB private memory at 09:55 on September 13 and 17.2 GiB in a subsequent check during the investigation.
   • That process consumed 6.12 CPU-seconds over an approximately five-second sampling interval: roughly one CPU core of activity.
   • At the initial snapshot, 11 ChatGPT UI processes together used 2.68 GiB private memory, 44 Node processes 1.32 GiB, and 46 Python processes 1.01 GiB. These are broad executable groups, not counts of independent MCP instances.
   • Windows reported 7.31 GiB free physical memory at that snapshot. Private committed memory and free physical memory are different measures.

   Model connection failures across tasks

   A bounded read-only inspection of the newest 3,000 log rows found six codex_core::responses_retry entries affecting six distinct tasks within approximately 50 seconds. Each showed a first retry (1/5), with errors including:

   stream disconnected before completion:
   failed to send websocket request: Connection closed normally
   

   and:

   stream disconnected before completion:
   WebSocket protocol error: Connection reset without closing handshake
   

   Task IDs, paths, and conversation contents are omitted. This establishes cross-task connection failures/retries, but does not distinguish client, network, or service causes or account for the entire reported delay.

   Important differences and limits

   • Of the newest 3,000 log rows, 1,628 fell within the preceding ten minutes at the initial check. No expected ordinal or database is locked messages appeared in that recent sample. This does not establish that the historical projection problem is repaired.
   • Separate local MCP connection failures mapped to Screaming Frog, which the user already expected to be offline. Those failures are not evidence that Unity caused the widespread stalls.
   • The large backend footprint and increase between snapshots do not alone prove a memory leak. No heap profile or causal link between memory usage and WebSocket failures has been established.
   • No processes were killed, app restarted, settings changed, or session databases modified during these checks.

   Please advise whether the performance/connection findings should be tracked separately and what narrowly scoped diagnostics would help. No raw logs, credentials, private task identifiers, or project content are attached.