›_ Codex Issues
Codex Issues / #33279

Windows Desktop: imported Continuing thread falls back to New Task and never renders

Open 💬 2 comments Opened Jul 15, 2026 by naterliuGamania
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.707.9981.0

What subscription do you have?

Not relevant to reproduction / not checked.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

在 Windows Codex Desktop 中，點選由 Continuing from [ChatGPT conversation] 工作流程建立的歷史 thread 時，前端會遺失該 thread 的 route，中央視窗立即回退為 「新任務」，而不是顯示原本的 title 與內容。

若在這個錯誤視圖按「繼續」，應用程式會顯示持續讀取或變得無法操作；原始 thread 的內容從未顯示。這不是資料遺失：app-server 已成功讀取並恢復同一個 thread。

這個問題也在另一個由相同匯入流程產生的 Continuing from … thread 重現。

What steps can reproduce the bug?

  1. 在 Windows Codex Desktop 以 Continuing from [ChatGPT conversation] 匯入／續接一段 ChatGPT 對話，建立 local thread。
  2. 讓該 thread 完成至少一個 turn。
  3. 重啟 Codex Desktop，從側欄任務清單點選這個 Continuing from … thread。
  4. 觀察中央視圖沒有載入原 thread，而是改成 「新任務」，內容區空白。
  5. 若按「繼續」，畫面進入持續讀取／無反應，原 thread 仍不會被渲染。

What is the expected behavior?

被選取的 Continuing from … thread 應保留其 title、路由與內容，並在恢復完成後顯示既有對話；它不應被替換成「新任務」。

Additional information

已去識別化的本機證據：

  • 受影響 thread 前綴：019f641d…
  • state record：source=vscode、history_mode=legacy、archived=0
  • session JSONL：263,899 bytes；title / preview / first_user_message 各為 727 字元；本機只有 88 個 active threads，因此不是大量歷史資料庫的情況。
  • 最近一次點選時：thread/read 成功，耗時 8 ms；thread/resume 成功，耗時 16,406 ms。
  • 日誌隨後記錄 maybe_resume_success 與 completed turn，但 UI 仍回退為「新任務」。
  • 失敗時 thread_stream_role_changed 的 ownerClientId=null，與前端 route fallback 相符。

已嘗試且無效的安全修復：

  • 完整重啟 Windows Desktop app。
  • 更新檢查（Microsoft Store 無較新版本）。
  • 備份後重設 electron-persisted-atom-state；此操作保留 session、projectless thread 資訊與輸出目錄，但問題仍可重現。

這個問題可能與 thread hydration / sidebar metadata 的效能問題相鄰（例如 #24510），但核心症狀是特定匯入 thread 在前端被錯誤替換為「新任務」，而非只有高 CPU 或慢載入。

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

English translation:

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

26.707.9981.0

What subscription do you have?

Not relevant to reproduction / not checked.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

In Codex Desktop for Windows, when selecting a historical thread created through the Continuing from [ChatGPT conversation] workflow, the frontend loses the route for that thread, and the central window immediately falls back to “New Task” instead of displaying the original title and content.

If “Continue” is clicked in this incorrect view, the application either keeps loading indefinitely or becomes unresponsive; the original thread content is never displayed. This is not data loss: app-server successfully reads and restores the same thread.

This issue is also reproducible with another Continuing from … thread produced through the same import workflow.

What steps can reproduce the bug?

  1. In Codex Desktop for Windows, import/continue a ChatGPT conversation using Continuing from [ChatGPT conversation] to create a local thread.
  2. Allow that thread to complete at least one turn.
  3. Restart Codex Desktop and select this Continuing from … thread from the task list in the sidebar.
  4. Observe that the central view does not load the original thread and instead switches to “New Task”, with an empty content area.
  5. If “Continue” is clicked, the view enters an indefinite loading/unresponsive state, and the original thread is still not rendered.

What is the expected behavior?

The selected Continuing from … thread should retain its title, route, and content, and display the existing conversation after restoration completes; it should not be replaced with “New Task.”

Additional information

De-identified local evidence:

  • Affected thread prefix: 019f641d…
  • state record: source=vscode, history_mode=legacy, archived=0
  • session JSONL: 263,899 bytes; title / preview / first_user_message are each 727 characters; there are only 88 active threads locally, so this is not a case involving a large historical database.
  • On the most recent selection: thread/read succeeded in 8 ms; thread/resume succeeded in 16,406 ms.
  • The logs subsequently recorded maybe_resume_success and a completed turn, but the UI still fell back to “New Task.”
  • At the time of failure, thread_stream_role_changed had ownerClientId=null, consistent with a frontend route fallback.

Safe fixes attempted without success:

  • Fully restarting the Windows Desktop app.
  • Checking for updates (no newer version was available in the Microsoft Store).
  • Resetting electron-persisted-atom-state after creating a backup; this preserved the session, projectless thread information, and output directory, but the issue remained reproducible.

This issue may be adjacent to thread hydration / sidebar metadata performance problems (for example, #24510), but the core symptom is that a specific imported thread is incorrectly replaced with “New Task” in the frontend, rather than merely causing high CPU usage or slow loading.

<!-- codex-issue-translator -->

github-actions[bot] contributor · 1 month ago

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

  • #32666
  • #33278

Powered by Codex Action