›_ Codex Issues
Codex Issues / #39575

Codex Desktop cannot archive sessions created in UTC+8 due to local-time rollout filenames

Open 💬 3 comments Opened Aug 20, 2026 by owenou-tw
💡 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)?

0.148.0-alpha.15

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64; timezone Asia/Taipei (UTC+8)

What issue are you seeing?

On Windows in the Asia/Taipei (UTC+8) timezone, archiving some Codex Desktop threads fails with:

failed to archive session: thread-store internal error: failed to archive thread: The system cannot find the file specified. (os error 2)

The session metadata timestamp is stored in UTC, but the rollout filename is generated with local time. When a thread is no longer loaded (for example after an app restart), the archive operation appears to reconstruct or look up the source filename using the UTC timestamp, so it cannot find the local-time-named file.

Example (IDs and user paths redacted):

  • Session metadata timestamp: 2026-08-19T10:17:47Z
  • Actual rollout filename timestamp: 2026-08-19T18-17-47
  • Time difference: +8 hours, matching Asia/Taipei
  • Archive lookup fails with os error 2

This reproduced across four separate threads created on the same machine. Three were forked/branched threads, but one affected root thread had no forked_from_id, so branching is not required to trigger the bug.

A newly created, currently loaded thread also has the same UTC/local-time filename mismatch but may still archive successfully while its actual path is cached in memory. The failure appears more likely after restart or when the thread status becomes notLoaded.

What steps can reproduce the bug?

  1. Run Codex Desktop on Windows with the system timezone set to Asia/Taipei (UTC+8).
  2. Create a new local Codex thread. A fork/branch is not required.
  3. Let the thread finish.
  4. Restart Codex so the thread is no longer loaded (observed status: notLoaded).
  5. Attempt to archive the thread from the sidebar or through the app's archive action.
  6. Observe thread not found or the thread-store os error 2.

Inspection of the local session shows that the JSONL session metadata uses a UTC timestamp while its rollout filename uses local time.

Workaround that confirmed the root cause:

  1. Back up the session.
  2. Rename the rollout file from its local-time timestamp to the corresponding UTC timestamp.
  3. Retry the native archive action.
  4. The archive succeeds immediately and the thread appears in the archived list.

No session IDs or personal paths are included here because they are not required to reproduce the timestamp mismatch.

What is the expected behavior?

Codex Desktop should archive the thread successfully regardless of the operating-system timezone. Session creation and archive lookup should use the same timestamp basis (preferably UTC), or archive lookup should use the stored session path/ID instead of reconstructing a filename from a timestamp.

Additional information

Observed with Codex App / embedded CLI version 0.148.0-alpha.15.

Four affected threads all had rollout filenames exactly eight hours ahead of the UTC timestamps in their session metadata. One was a root thread with no forked_from_id; the other three were forked descendants. This rules out branching as a necessary cause.

The same +8-hour filename mismatch is also present on a newly created, currently loaded root thread. This suggests the archive failure may depend on the thread being unloaded or the app having restarted: a loaded thread can use its cached actual path, while a notLoaded thread may reconstruct the path from the UTC metadata timestamp.

After correcting each affected filename to UTC, the built-in archive action returned success and the threads appeared in the archived list.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 8 days ago

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

  • #39492
  • #39471
  • #39468

Powered by Codex Action

czwaxm · 8 days ago

I can reproduce the same pattern on Windows UTC+8, and my local evidence matches the UTC-vs-local rollout filename hypothesis.

Details from one affected local Codex task:

  • Time zone: China Standard Time / UTC+8.
  • Thread id: 01a00ed1-77d0-7381-bb3a-ab2dea1ff3ef.
  • The task is notLoaded, but read_thread still works and shows the latest turn completed successfully.
  • Native archive through the app task-management interface fails with:
failed to archive session: thread-store internal error: failed to archive thread: 系统找不到指定的文件。 (os error 2)
  • The rollout JSONL still exists and is readable under .codex/sessions/....
  • archived_sessions exists, but no archived copy for this thread is created.
  • thread-writer-locks has no lock for this thread.
  • Opening/navigating to the thread and retrying archive gives the same error.

Timestamp mismatch for the same thread:

session_meta.timestamp: 2026-08-17T08:23:23.979Z
actual rollout filename: rollout-2026-08-17T16-23-23-01a00ed1-77d0-7381-bb3a-ab2dea1ff3ef.jsonl

The filename is exactly +8 hours from the UTC metadata timestamp. This is the same task that fails archive with os error 2, while the source JSONL file exists. I have not modified SQLite or renamed the rollout file on this machine, so this is just an additional reproduction data point rather than a workaround confirmation.

norberttrupiano-wq · 2 days ago

Independent reproduction

I found a strong independent reproduction consistent with #39575 on Windows, using the Europe/Paris timezone rather than Asia/Taipei. This is a retrospective sample of 39 old automation-created threads.

Environment

  • OS: Windows
  • Timezone: Europe/Paris
  • Period examined: 2026-05-27 through 2026-06-29
  • Europe/Paris was UTC+2 throughout this entire period
  • Sample: 39 threads — 33 daily automation runs and 6 weekly snapshots

Observations

  • All 39 threads are still recorded with archived = 0.
  • All 39 referenced rollout JSONL files exist and are non-empty.
  • Every JSONL line parses successfully as JSON.
  • Every JSONL contains the expected thread ID.
  • PRAGMA integrity_check returns ok.
  • 35 threads have a normal Windows rollout_path beginning with C:\....
  • 4 threads have a verbatim/extended path beginning with \\?\C:\....
  • The 35 threads with normal paths also fail to archive, so the \\?\ prefix cannot explain the general failure in this sample.

Timestamp pattern

For 39/39 rollout files:

  • the timestamp embedded in the rollout filename is Europe/Paris local time;
  • session_meta.payload.timestamp is UTC;
  • the difference matches UTC+2 exactly after accounting for the filename's whole-second precision.

The invariant observed across the full sample is:

rollout filename timestamp = session_meta.payload.timestamp converted to Europe/Paris, truncated to seconds

An anonymized example:

rollout-2026-05-27T20-02-08-<thread-id>.jsonl

with:

session_meta.payload.timestamp = 2026-05-27T18:02:08.132Z

The direct subtraction is +01:59:59.868 because the filename omits milliseconds; after truncating the metadata timestamp to seconds, the offset is exactly +02:00:00.

Why this matters

This suggests that the behavior described in #39575 is not specific to UTC+8 and is also reproducible in Europe/Paris at UTC+2, across a substantially larger sample.

It also affects threads whose stored Windows paths are otherwise normal. The four \\?\ paths may combine two separate defects, but the 35 normal paths isolate the local-time/UTC filename mismatch from the path-prefix issue.

This is a strong independent reproduction consistent with #39575, but not definitive causal proof.

No local modification performed

This investigation was read-only. No rollout file was renamed, no JSONL content was changed, no SQLite row or archive flag was modified, and the causal rename workaround described in #39575 has not been attempted on this dataset.

I can provide additional anonymized aggregate details if useful to the maintainers.