›_ Codex Issues
Codex Issues / #39627

[Windows][26.818.2441.0] Legacy local tasks still fail to archive while new tasks archive successfully

Resolved 💬 10 comments Opened Aug 20, 2026 by xiaodeng2025 Closed Aug 26, 2026
💡 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)?

Codex Desktop MSIX: 26.818.2441.0 (x64)

Additional runtime evidence:

  • App-server reported version: 0.148.0-alpha.21
  • Desktop runtime release recorded in the log: 26.818.21641

What subscription do you have?

ChatGPT subscription (tier omitted because it does not appear relevant to this local archive failure).

What platform is your computer?

Windows 25H2 x64, build 26200.9168.

What issue are you seeing?

The latest Windows desktop update does not fix archive failures for existing local Codex tasks, while a newly created local task archives successfully in the same app session.

I performed a controlled A/B test after updating:

| Task type | Result |
| --- | --- |
| Three pre-existing local tasks | All failed to archive |
| One newly created minimal local task | Archived successfully |

For each existing task, the normal archive UI path reached thread/archive and returned in approximately 92–98 ms:

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

For the three failing tasks, read-only inspection found all of the following:

  • threads.archived = 0 and archived_at = NULL after the failure.
  • The rollout JSONL referenced by each threads.rollout_path exists and is non-empty.
  • Each stored rollout_path begins with the Windows verbatim prefix \\?\C:\....
  • The rollout remains under active sessions; no archived copy is created.

For the newly created test task:

  • The same archive backend operation succeeded.
  • The database row became archived and received an archive timestamp.
  • The rollout moved to archived_sessions.
  • Its stored rollout path did not use the \\?\ prefix.

This rules out a general inability to archive, an unwritable archive directory, or a UI-only click-handler failure. The differentiator is the legacy task state/path form.

What steps can reproduce the bug?

  1. On Windows Codex Desktop 26.818.2441.0, select an existing completed local task whose threads.rollout_path uses the \\?\C:\... form.
  2. Use the normal Archive action.
  3. Observe the “unable to archive” result and the thread-store ... (os error 2) response.
  4. In the same app session, create a new minimal local task and let it complete.
  5. Archive the new task.
  6. Observe that the new task archives successfully.

What is the expected behavior?

Existing local tasks should archive exactly as new local tasks do, regardless of whether their persisted rollout path uses a normal drive path or the Windows extended-length path form.

Additional information

This is related to, but intentionally submitted separately from, #39239 because it demonstrates that the regression still reproduces on the newer package 26.818.2441.0 and includes a same-session legacy-versus-new task control.

The \\?\ path form is a strong candidate trigger, but I am not claiming it explains every archive failure. Other reports have described similar symptoms without that prefix.

No local database edits, session-file moves, cache deletion, application reset, downgrade, or repair operation was performed. No thread IDs, local paths, task titles, account identifiers, conversation contents, or raw logs are included here.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 8 days ago

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

  • #39454
  • #39600
  • #39239
  • #39378
  • #39209

Powered by Codex Action

wssf812 · 8 days ago

I tested that starting from vscode plugin 26.814.41407, it is no longer possible to archive, and then downgraded to 26.810.52044 to archive, even if the symbol "\\?\" exists

The newly created ones that can be archived mainly do not have the symbol "\\? \". If you restart them, Codex will automatically add this symbol, and then you will find that even the newly named ones that can be archived cannot be archived

You can try lowering the version first.

berkyuo2-cpu · 7 days ago

Current-build follow-up: two confirmed archive failure modes and supported recovery evidence

I reproduced this on a separate Windows installation with the same current build:

  • Codex Desktop MSIX: 26.818.2441.0 x64
  • app-server: 0.148.0-alpha.21
  • Windows 10 22H2, build 19045, x64

A read-only state/filesystem audit found:

  • 1,096 thread rows and 282 physical rollout files.
  • Four existing user-root threads stored rollout_path in the \\?\C:\... form.
  • All four referenced JSONL files existed and were non-empty.
  • One of those threads produced three UI archive failures with thread/archive -32603 / os error 2.
  • The physical rollout set had no zero-byte files, duplicate UUIDs, or thread-ID/path mismatches.

I also confirmed a second failure mode in a different thread:

  1. The rollout had already moved from sessions to archived_sessions.
  2. The SQLite row still had archived=0 and the old active rollout path.
  3. Later archive attempts looked for the old source and returned os error 2.

That is evidence that the filesystem move and DB update can be left partially committed, independently of the \\? path-normalization case.

Supported recovery experiment

After taking an online SQLite backup and recording file length, timestamp, and SHA-256:

  • The installed supported CLI (codex-cli 0.144.1) successfully ran codex archive <thread-id> on the repeatedly failing prefixed-path thread.
  • Exit code was 0.
  • The DB became archived=1, archived_at was populated, and the stored path was normalized under archived_sessions.
  • Source/destination count was exactly one and SHA-256/length were unchanged.
  • The app's archived-task API could read the result.
  • For the other three prefixed-path threads, supported archive followed by unarchive normalized their paths while leaving them active. All three retained exact length and SHA-256.
  • Final SQLite PRAGMA integrity_check returned ok; remaining extended-length rollout paths: 0.
  • Re-running the supported archive command also reconciled the separate partial-commit case.

No manual SQLite update, fake JSONL, cache reset, raw file move, or session deletion was used.

Suggested invariants/fixes:

  1. Normalize equivalent Windows drive and verbatim paths before validation/move.
  2. Make rollout move + thread-row update atomic, or roll back the move if the DB write fails.
  3. Make archive idempotently reconcile both partial states (destination exists/DB active and source exists/DB archived).
  4. Preserve the actual failing source/destination/auxiliary path in the error context.
  5. Add a supported Desktop migration/recovery path for legacy stored paths so users do not need a separate CLI operation.

No thread IDs, task titles, usernames, private paths, conversation content, or raw logs are included here.

thaiwu0107 · 7 days ago

Additional reproduction on Windows Codex Desktop on 2026-08-20:

  • thread/archive failed for a completed/not-loaded local task with thread-store internal error ... The system cannot find the file specified. (os error 2).
  • The rollout JSONL existed, was non-empty, and the SQLite database passed PRAGMA integrity_check.
  • The affected threads.rollout_path used the Windows verbatim form \\?\C:\....
  • After backing up the database and removing only the leading \\?\ from that one inactive thread's rollout_path, the exact same official archive operation succeeded immediately; the task then appeared in the archived-task listing.
  • A read-only scan after the repair found another currently active task had again been persisted with the same verbatim prefix, while there were zero missing rollout files. This confirms the app is still generating the problematic path form and the workaround is not durable for resumed/active tasks.

No thread IDs, task titles, conversation contents, account identifiers, or private local paths are included.

berkyuo2-cpu · 7 days ago

Follow-up: Desktop rewrites the normalized legacy path back to \\?\C:\...

I reproduced the failure again on Codex Desktop 26.818.2441.0 / app-server 0.148.0-alpha.21 and found why the earlier supported CLI round trip was not durable.

New evidence
  1. A supported archive -> unarchive round trip had normalized both cwd and rollout_path in SQLite, and the rollout file hash/length were unchanged.
  2. After the same task was opened/resumed in the still-running Desktop process, the row was written back with legacy extended-length values:
  • cwd = \\?\C:\...
  • rollout_path = \\?\C:\...\.codex\sessions\...jsonl
  1. The referenced JSONL still physically existed at that path. This is not a missing-file case.
  2. Desktop logs show the task being resumed and taking the owner role, followed by two UI thread/archive requests. Both failed with RPC -32603 and Windows os error 2.
  3. Running the supported CLI archive <thread-id> again, and this time leaving the task archived, succeeded.
Post-repair verification
  • SQLite: archived = 1, archived_at populated, and rollout_path is the canonical non-\\?\ path under .codex\archived_sessions.
  • File system: zero active copies, exactly one archived copy.
  • The JSONL byte length and SHA-256 are identical before and after the move.
  • PRAGMA integrity_check returns ok.
  • The task appears in the archived-task API and is absent from the active-task API.
  • A follow-up monitor showed that the still-running Desktop process did not revert the final archived state.
Implication

The long-lived Desktop process appears to retain a stale in-memory/cache copy of the legacy \\?\ paths and writes it back when the task is resumed. Therefore a DB-only normalization, or an archive -> unarchive repair while the same Desktop process remains alive, can be undone.

Suggested fix / regression coverage
  • Normalize legacy paths in both the persistent thread row and any live/cached thread/session object atomically.
  • Invalidate or refresh the cached thread object after archive/unarchive and after migration.
  • Avoid resuming/acquiring ownership of a task as a prerequisite for archiving it, or make archive resolve the canonical rollout path independently.
  • Add a Windows regression test: seed a task with \\?\ cwd and rollout_path, open/resume it, archive it from the Desktop UI, and verify the canonical path, DB state, and file move remain consistent.
  • Also test recovery from the partial state where the file moved but the DB row did not commit.

This explains why the problem affects multiple tasks rather than one conversation.

berkyuo2-cpu · 7 days ago

Additional reproduction: three independent tasks fail together, and the Desktop toast misattributes the error to config.toml

I reproduced the same archive regression again on the same Windows Codex Desktop installation, this time against three separate completed/not-loaded local tasks from different dates and workspaces.

Reproduction
  • The supported Desktop archive API was called once for each task.
  • All three calls failed independently with the same error:
  • failed to archive session
  • thread-store internal error
  • The system cannot find the file specified. (os error 2)
  • All three SQLite rows had both cwd and rollout_path stored in the Windows verbatim \\?\C:\... form.
  • All three referenced rollout JSONL files physically existed and were non-empty.
  • PRAGMA integrity_check returned ok before recovery.
  • The user's global config.toml parsed successfully as TOML.

The Desktop UI nevertheless displayed the archive failure inside a red toast headed "Model settings could not be updated. Check your config.toml", with thread not found: <id> as the detail. The heading is misleading: the operation being performed was task archiving, the configuration file was valid, and the thread rows/files existed.

Supported recovery and verification

Running the installed supported CLI codex archive <thread-id> sequentially for the same three IDs succeeded for all three with exit code 0.

For every task after recovery:

  • SQLite had archived = 1 and a populated archived_at.
  • rollout_path was canonicalized under .codex\archived_sessions without the verbatim prefix.
  • The task disappeared from the active-task API and appeared in the archived-task API.
  • File byte length and SHA-256 were identical before and after the move.
  • Final PRAGMA integrity_check returned ok.
  • A follow-up check after 10 seconds showed all three records still archived and canonical.
Additional implications / requested coverage
  • This is systemic and can affect multiple otherwise healthy tasks at once, including newly created tasks.
  • The Desktop/API archive path and the supported CLI archive path do not currently resolve the same stored Windows path equivalently.
  • The UI toast should report the archive/thread-store failure directly and must not label it as a model-settings or config.toml failure.
  • Please add a batch regression test with multiple prefixed rows whose JSONL files exist, plus a UI/error-mapping test that ensures archive failures are not surfaced as configuration errors.

No task titles, thread IDs, usernames, private paths, conversation content, or raw logs are included.

berkyuo2-cpu · 7 days ago

Affected account identifier (shared with the user's explicit permission)

For account-level follow-up on this regression:

  • GitHub: @berkyuo2-cpu
  • Codex authentication mode: ChatGPT
  • Codex account ID: d61199e8-75fe-4136-bdc6-a0fc146118f9

No email address, access/refresh token, API key, cookie, private path, or conversation content is included. If a goodwill credit or account-specific follow-up is available for the repeated archive failures, please associate it with this account or contact the user privately through GitHub.

naipi11 · 7 days ago

For a local Windows task whose Desktop Archive action returns os error 2, a supported recovery path reported on the current build is:

  1. Fully quit the Codex/ChatGPT desktop app so it cannot rewrite the task path while you repair it.
  2. From the installed Codex CLI, run codex archive <thread-id> for the affected task.
  3. Confirm the command exits successfully.
  4. Verify that the task disappears from the active list and appears in archived tasks.
  5. Reopen the desktop app only after the archive state is confirmed.

This avoids editing state_5.sqlite, moving rollout files manually, or deleting local data. Limitation: it applies to local tasks when the installed CLI exposes the archive command; it does not repair cloud conversations or the underlying Desktop path-normalization bug.

xiaodeng2025 · 7 days ago

Resolved in current Windows build

After updating to Codex Desktop 26.818.3698.0 on Windows, I re-tested the archive behavior:

  • The three previously failing legacy local tasks now archive successfully.
  • Additional older local tasks also archive successfully from the UI.
  • New tasks continue to archive successfully.
  • I can no longer reproduce the original thread not found / os error 2 archive failure.

The issue appears fixed in this build. Thank you.

naipi11 · 6 days ago

Thanks for the current-build confirmation. Desktop 26.818.3698.0 appears to have fixed the legacy local-task archive failure.

If the update is available:

  1. Update the desktop app.
  2. Retry Archive on one previously failing local task.
  3. Verify that it disappears from the active list and appears in archived tasks.

The CLI codex archive method I shared earlier was only a temporary recovery path for affected builds; it is not needed when the current Desktop build archives the task successfully. Users still on an affected build should avoid editing the database or moving rollout files manually.