Skip to content

WSL Desktop cannot archive tasks stored under previous CODEX_HOME after home change #33815

Open

Description

@solankydev

Summary

Codex Desktop running its agent in WSL can still discover and read a task after the Desktop WSL app-server's CODEX_HOME changes, but archiving that task fails if its rollout remains under the previous CODEX_HOME.

The archive request fails with:

rollout path `/mnt/c/Users/<redacted>/.codex/sessions/.../rollout-...jsonl` must be in sessions directory

This is not a Windows-native task. It was created by the WSL agent while the WSL app-server used a Windows-mounted CODEX_HOME.

Environment

  • Codex Desktop for Windows: 26.715.2305.0
  • Bundled WSL Codex runtime recorded by the task: 0.145.0-alpha.18
  • Agent execution environment: WSL2
  • Task working directory: WSL-native Linux path
  • Old Desktop WSL CODEX_HOME: Windows-mounted path under /mnt/c/Users/<redacted>/.codex
  • New Desktop WSL CODEX_HOME: Linux-native path under /home/<redacted>/.codex
  • SQLite home remained Linux-native/shared

Steps to reproduce

  1. Configure Codex Desktop to run its agent in WSL.
  2. Start the WSL app-server with CODEX_HOME pointing to a Windows-mounted directory.
  3. Create and complete a task whose working directory is on the WSL-native filesystem.
  4. Change the WSL app-server's CODEX_HOME to a Linux-native directory and restart Codex Desktop.
  5. Observe that Desktop can still discover/read the old task by ID through the shared task index/state database.
  6. Attempt to archive the old task.

Actual behavior

The old rollout path is resolved successfully from stored task metadata, but thread/archive rejects it because it is outside the current CODEX_HOME/sessions.

The task remains unarchived and its rollout file remains intact.

Expected behavior

If Desktop can discover and read a task whose rollout is stored under a previously configured Codex home, it should also be able to archive it safely.

Possible approaches:

  • Resolve the owning sessions root from the stored rollout path and archive within that same Codex home.
  • Track the owning Codex home in thread metadata and route archive/unarchive operations accordingly.
  • Explicitly migrate or import old-home tasks into the current store.
  • If cross-home archival is intentionally unsupported, stop indexing those tasks as fully manageable and return an actionable error explaining how to archive them using the original home.

Suspected root cause

The current local archive implementation resolves the rollout through thread lookup/state metadata, then scopes it against:

store.config.codex_home/sessions

That creates an asymmetry: cross-home lookup/read succeeds, but archive validates against only the current home.

Relevant current code:

  • codex-rs/thread-store/src/local/archive_thread.rs
  • codex-rs/thread-store/src/local/helpers.rs::scoped_rollout_path

Related but distinct

Workarounds

A restart-based workaround is to temporarily restore the previous WSL app-server CODEX_HOME, restart Desktop, archive the old-home tasks, then restore the Linux-native home.

Recent Codex CLI versions also expose codex archive <session>; invoking it with a one-command CODEX_HOME override matching the rollout's original home may avoid restarting Desktop, but this should be documented or made unnecessary by cross-home routing.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jul 17, 2026
  2. kendonB commented on Jul 18, 2026

    @kendonB

    Possibly also seeing this issue (see 019f63bb-0dd1-79d1-b5ad-7f5adc61a2bb)

  3. kendonB commented on Jul 20, 2026

    @kendonB

    Two additional findings (reported by 5.6 Sol xhigh):

    This also affects Windows-native tasks imported into the current WSL catalogue, not only WSL-created tasks. I reproduced it with one of each; both remain valid and readable as notLoaded threads.

    For these inactive threads, Desktop does not send thread/archive. The Electron inactive-archive helper checks the stored rollout against the current CODEX_HOME/sessions and returns success: false when it belongs to the previous Windows-mounted home. No archive request appears in the app-server logs, and the UI provides no actionable error.

  4. boombx403-byte commented on Aug 18, 2026

    @boombx403-byte

    Hi @solankydev, cross-platform WSL/Windows path mismatches often make healthy transcripts look broken when workspace contexts change. Codex Rescue Alpha5 explicitly separates transcript integrity from workspace path-family portability without rewriting saved paths.

    If you'd like to check the local rollout safely:

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

    Please sanitize private paths before posting any output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions