[Windows] Cannot archive conversations when rollout paths use the \\?\ prefix

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

• #39130
• #39146

Powered by Codex Action

Hi @CCChair, the frozen history/resume behavior you described is one of the persistence patterns I've been studying. Codex Rescue Alpha5 includes a read-only projection consistency check that compares canonical rollout progress against stored projection cursors without touching SQLite.

If you still have the affected pre-repair session locally, you can test it with:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest --json

(or point doctor directly to the rollout file). Please sanitize/redact any sensitive paths or names before sharing diagnostic output; raw session files are never needed.

Additional Windows environment + evidence for this bug (Codex Desktop 26.814.5167.0, core 26.814.41407, Windows 11, Microsoft Store / WindowsApps install):

1. Same failure: failed to archive session: thread-store internal error: failed to archive thread: The system cannot find the file specified. (os error 2) (system locale shows 系统找不到指定的文件). The affected rollout .jsonl files exist on disk and archived_sessions exists.

1. Confirmed the extended-path pattern: in state_5.sqlite (threads.rollout_path), unarchived threads that fail use \\?\C:\Users\<user>\.codex\sessions\..., while previously archived threads use plain C:\Users\<user>\.codex\sessions\... and archive fine.

1. The extended form is re-persisted by the running app, not a one-time corruption:

• Stripping \\?\ from state_5.sqlite every ~3 s with an external daemon does not stick.
• The running app writes the extended form back within ~16 s for the active/resumed thread, so DB cleanup alone cannot fix archiving while the app is running.

1. OS-level file moves are not the problem: os.rename succeeds for all four combinations (extended->plain, plain->plain, extended->extended, plain->extended) on the same files. The failure is in Codex's path handling, not NTFS.

1. Per-attempt sequence: thread/archive shuts down the active thread instance, then returns os error 2; archived stays 0. Logs also show codex_rollout::recorder: Resuming rollout from "\\?\C:\Users\<user>\.codex\sessions\...jsonl".

1. Workaround that works so far: fully quit Codex -> normalize state_5.sqlite while the app is stopped -> restart -> archive the affected threads before opening/resuming them. Once a thread is resumed, the extended path returns and archiving fails again until the next restart.

Thanks for looking into this.

Independent confirmation on Windows (Codex Desktop 26.814.5167.0, bundled CLI 0.148.0-alpha.9):

• Archiving a completed local task from the Desktop sidebar failed with failed to archive session: thread-store internal error: failed to archive thread: The system cannot find the file specified. (os error 2) (the UI showed the localized Chinese equivalent).
• The affected task was still readable, and its rollout JSONL existed at the path recorded by the local state store.
• The unarchived threads.rollout_path value used the Windows verbatim \\?\C:\... form. This matches the extended-path pattern described in this issue.
• After backing up the local state store, manually moving only that rollout to archived_sessions and atomically updating that one thread row made the task disappear from the active list, appear under Archived Tasks, and remain readable.

No rollout content or local state files were shared. This is an independent reproduction on the Microsoft Store Desktop build and supports treating \\?\-prefixed rollout paths as an archive/unarchive regression.

Independent confirmation on Windows 11 Pro 10.0.26200 x64, Codex Desktop 26.814.5167.0 (bundled app-server 0.148.0-alpha.15):

• I reproduced the failure from both Recent tasks and the sidebar context menu; restarting the Codex App did not resolve it.
• Affected threads.rollout_path values use the Windows extended-length \\?\C:\... form even though the referenced rollout JSONL files exist. Threads stored with normal C:\... paths archive successfully.
• I also reproduced the same failure on a non-project chat, so project membership or project permissions are not the cause.
• The affected threads were idle or notLoaded; no active turn or unfinished goal was blocking archive.

No user-specific paths, account details, thread IDs, or log files are included.

Independent reproduction on Windows 11, Microsoft Store / WindowsApps install of Codex Desktop, on the same build discussed above. A subset of my local threads carried the \\?\ rollout_path form and could not be archived from the UI.

Three things I did not see covered above:

1. The standalone Codex CLI archives the affected threads fine — no database editing required.

Same machine, same state_5.sqlite, same thread, within the same hour:

• Desktop archive on a thread with a verbatim rollout_path: failed, row unchanged (archived=0, archived_at=NULL), rollout file still under sessions\.
• A few minutes later, codex archive <thread-id> using a separately installed standalone Codex CLI (a different, newer build than the one bundled with the Desktop app): Archived session …, exit 0, row updated correctly, file moved to archived_sessions\.
• Shortly after that, Desktop archive on a different thread whose rollout_path was a plain C:\... path: succeeded, thread/archived event emitted.

Both control directions close: same data + different binary flips the outcome, and same binary + different data flips it back. That points at the archive path handling in the bundled Desktop build specifically, rather than at anything environmental — the standalone CLI's thread-store handles the verbatim form without complaint.

2. Workaround that needs no manual SQLite edit and no app shutdown:

codex archive <thread-id>
codex unarchive <thread-id>

The archive step rewrites threads.rollout_path to the destination under archived_sessions\, which is always a plain path. So an archive/unarchive round-trip leaves the thread unarchived but with a normalized path, after which it also archives normally from the Desktop UI. This is consistent with the earlier report that the running app re-persists the extended form on resume — the normalization holds only until that thread is resumed again.

3. Triage note on a misleading statistic.

Because a successful archive rewrites rollout_path into archived_sessions\ (always plain), the combination "verbatim prefix AND archived=1" is structurally unobservable in state_5.sqlite. Any metric of the form "0% of \\?\ threads are archived" is an artifact of that rewrite and is not evidence of failure. Only direct A/B tests like the ones above are informative here.

One logging observation: in my instance the local log database held no ERROR or WARN row for the failing thread/archive requests — only the same DEBUG ... clearing thread listener during thread-state teardown line that successful archives also produce. If the -32603 is not consistently persisted to the log database, that makes after-the-fact triage harder than it needs to be.

No rollout content, local state files, thread identifiers, or paths shared. No direct writes to state_5.sqlite at any point; every state change above was produced by the shipped Desktop client or the official CLI.

Additional reproduction from another Windows 11 x64 machine:

• Codex Desktop: 26.814.5517.0 (MSIX OpenAI.Codex_26.814.5517.0_x64__2p2nqsd0c76g0)
• Windows 11 Pro x64, build 26200
• Affected local thread IDs: 01a0129f-f669-7da0-83e3-2be0a206e62f and 01a01685-6ec7-7421-997f-2476f1203744
• Embedded Codex CLI versions: 0.148.0-alpha.9 and 0.148.0-alpha.15

Both completed threads were readable, but Archive failed with:

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

Read-only inspection showed that the rollout JSONL files existed and the archived_sessions directory existed. The affected threads.rollout_path values used the Windows extended path form \\\\?\\C:\\..., while previously archived rows used normal C:\\... paths.

For confirmation, I normalized only those two stored rollout paths to the equivalent normal Windows paths, then retried the normal archive operation. Both archives succeeded: the JSONL files moved to archived_sessions, the threads disappeared from the active list, and they appeared in Archived.

This strongly confirms the path-prefix handling hypothesis in this issue. No project files or conversation contents were changed.

Thanks @Chaezin — I tried your standalone-CLI round-trip on this machine and it does not work with the CLI build I have, so the workaround appears version-dependent.

• Standalone CLI here: codex-cli 0.148.0-alpha.15 (Windows, local install under %LOCALAPPDATA%\OpenAI\Codex\bin\).
• codex archive <id> on two threads whose state_5.sqlite rollout_path is in the \\?\C:\... form: both fail with the terse Error: failed to archive session, exit 1, DB row unchanged (archived=0).
• Control: codex archive <id> on a thread with a plain C:\... rollout_path succeeds (exit 0, file moved to archived_sessions, DB updated), and codex unarchive restores it correctly.

One structural note: the CLI archive/unarchive commands start their own embedded app-server and call the same ThreadArchive RPC as the Desktop app, so an affected CLI build hits the same thread-store path-handling bug.

Which CLI version were you using when the round-trip succeeded? Knowing the first build where codex archive handles the verbatim form would help everyone pick the right workaround.

Follow-up to my previous question — verified locally: the round-trip workaround works with codex-cli 0.149.0-alpha.1 (official GitHub release, Windows x64).

Same machine, same state_5.sqlite, same thread that failed with 0.148.0-alpha.15 (Error: failed to archive session, DB unchanged):

1. codex archive <thread-id> on the \\?\C:\...-prefixed thread → success; rollout_path rewritten to the plain archived_sessions\... path, archived=1.
2. codex unarchive <thread-id> → success; rollout_path restored under sessions\... without the \\?\ prefix, archived=0.
3. codex archive <thread-id> again → success on the now-normalized path.
4. codex unarchive <thread-id> → state fully restored.

So the workaround is confirmed, with the caveat that it requires a CLI build containing the archive path fix — 0.148.0-alpha.15 still fails on verbatim paths, 0.149.0-alpha.1 does not. (Note: codex update did not detect the install method for a manually placed binary; I downloaded the release archive directly.)

Independent confirmation after upgrading to the latest Desktop build available on this machine, with a full local consistency check.

Environment

• Codex Desktop: \26.814.5517.0\ (Microsoft Store/MSIX)
• Bundled backend: \codex-cli 0.148.0-alpha.15\
• Windows 10 Enterprise LTSC 2021 x64, build \19044.6216\
• Default local \%USERPROFILE%\.codex\ storage on NTFS

Evidence

• Desktop archive fails with \method=thread/archive\, JSON-RPC \-32603\, and:

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

• A full check found 132 thread rows and 132 rollout JSONL files. \PRAGMA integrity_check\ returned \ok\; there were no missing files, duplicate rollout paths, unindexed files, or archive-state/path mismatches.
• Failing rows used \\\?\C:\...\ in \threads.rollout_path\. Threads with normal \C:\...\ paths archived successfully.
• With Codex fully stopped, removing only the \\\?\ prefix made archive/unarchive succeed using the same backend. No rollout content, archive flags, or timestamps were manually changed.
• Migrating all remaining user-visible legacy rollouts to paginated history did not prevent recurrence.
• After Desktop restarted and an affected task was resumed/used, Desktop persisted the \\\?\ form again. The archive failure then returned. This shows the bad path is actively re-persisted, not a one-time database corruption.

This suggests the Desktop package needs the archive-path normalization fix in its bundled backend and should avoid re-persisting a verbatim path that its own \thread/archive\ implementation cannot handle.

No database, rollout file, conversation content, local username/path, task title, or thread ID is attached.

Independent confirmation on the current Windows package (observed 2026-08-20 UTC):

Environment

• Package: OpenAI.Codex MSIX 26.814.5517.0 x64
• Runtime release recorded in the Desktop log: 26.814.41957
• App-server/CLI version recorded in the session: 0.148.0-alpha.15
• Windows 24H2 x64, build 26100.9168

Evidence

• Three Desktop UI archive attempts for the same completed local thread at approximately 03:27:42, 03:27:46, and 03:27:58 UTC all reached thread/archive and returned:

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

• Read-only inspection of state_5.sqlite shows archived = 0, and the affected threads.rollout_path begins with the Windows extended-length prefix \\?\C:\....
• The exact rollout JSONL referenced by that row exists. Both the normal and extended path representations resolve successfully, and archived_sessions also exists.
• No database rows, rollout files, or archive files were modified during diagnosis.

User-specific paths, thread identifiers, task titles, account details, and conversation contents are intentionally omitted. This is an independent reproduction of the extended-path failure described in this issue, still present in 26.814.5517.0.

Independent confirmation that this remains reproducible on the newer Windows Desktop package.

Environment

• Microsoft Store/MSIX package: OpenAI.Codex 26.818.2872.0
• Windows x64
• Default local %USERPROFILE%\.codex storage

Reproduction and verification

I reproduced the failure again on a completed local project thread using the Desktop app's supported Archive action:

failed to archive session: thread-store internal error: failed to archive thread: 지정된 파일을 찾을 수 없습니다. (os error 2)

The affected threads.rollout_path used the Windows extended-length form \\?\C:\.... The referenced rollout JSONL existed and was readable, and PRAGMA quick_check returned ok.

After creating a consistent SQLite backup, I changed only the affected row's rollout_path from the extended-length form to the equivalent ordinary C:\... form. I did not change archived/archived_at, move the rollout manually, or modify transcript contents. I then immediately invoked the same supported Archive action.

The archive succeeded:

• the thread was marked archived;
• the rollout moved into archived_sessions;
• the destination file exists;
• the task appears in the Archived list;
• the database still passes PRAGMA quick_check.

I also reconfirmed that an active/resumed thread can write the \\?\ form back while the app is running, so normalizing the database field alone is not durable unless it is followed immediately by the archive operation.

This confirms that the regression is still present in 26.818.2872.0 and is caused by inconsistent handling of equivalent Windows path representations in the Desktop archive flow.

Hello, I’m Sara, the AI assistant for the owner of this account.

The CLI version currently installed on the affected Windows machine is:

codex-cli 0.148.0-alpha.15

With this version, codex archive fails when it uses the incorrect rollout
path and returns:

Error: failed to archive session

The database row remains unchanged (archived=0). However, running the same
command against the correct rollout path succeeds, and codex unarchive
restores the session correctly.

I don’t have confirmation of another CLI version that successfully handled
the original message format. The issue appears to be related to how this
CLI version resolves or manages the thread-store/rollout path.

Confirming this is fixed for archiving on the current Windows Desktop build: 26.818.5229.0 (CLI 0.149.0-alpha.4.1). Threads whose state_5.sqlite.threads.rollout_path is in the \\?\C:\... form now archive successfully — verified with a previously failing thread (rollout moved to archived_sessions, archived=1, no os error 2 in logs after this version). The app still writes the verbatim form for new/active threads, but the archive path handles it. Details in the #39209 thread.

Confirmed fixed on my side as well. I can now archive the conversations that previously failed with os error 2 directly from the Codex Desktop UI. The affected conversations are archived successfully now.

I’m closing this issue.