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

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.

Start at the thread-store archive action and the rollout filename generation or lookup, focusing on threads with status notLoaded after an app restart. Reproduce on Windows in Asia/Taipei, then verify that archiving succeeds without renaming the rollout file and that the thread appears in the archived list.