[Codex Desktop][Remote SSH] Archiving a thread fails with EXDEV when archived_sessions is on another filesystem

Open 💬 1 comment Opened Aug 1, 2026 by chac4l
💡 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?

Codex Desktop 26.727.6591.0; remote Codex CLI/app-server 0.146.0.

What subscription do you have?

ChatGPT subscription (exact tier intentionally omitted because it does not appear relevant).

What platform is your computer?

  • Local client: Windows x64
  • Remote host: Linux x86_64
  • Connection: Codex Desktop Remote SSH

What issue are you seeing?

Archiving a thread from a Remote SSH project fails in Codex Desktop with a generic Failed to archive message.

The remote app-server returns:

failed to archive session: thread-store internal error: failed to archive thread: Cross-device link (os error 18)

Local threads archive normally.

On the affected remote host, the active and archived session directories were valid directories but lived on different filesystems. The archived-session directory was mounted from a separate volume for cold-storage purposes. The thread was completed and readable, and authentication was healthy.

This appears to happen because the thread store uses a filesystem rename from the active session tree to the archive directory. A rename cannot cross filesystem boundaries and returns EXDEV.

What steps can reproduce the bug?

  1. Configure Codex Desktop with a Linux Remote SSH project.
  2. Keep the active session directory on the primary filesystem.
  3. Mount or bind-mount the archived-session directory from a different filesystem.
  4. Create and complete a normal remote thread.
  5. Archive the thread from Codex Desktop.
  6. Observe the generic archive failure in the UI and Cross-device link (os error 18) from the remote thread store.

The same thread archived successfully immediately after both directories were placed on the same filesystem.

What is the expected behavior?

Ideally, archive should support cross-filesystem destinations using a safe fallback such as copy to a temporary destination file, fsync, atomic rename within the destination filesystem, then unlink the source and update the state database.

If cross-filesystem archival is intentionally unsupported, Codex should:

  • detect the condition before attempting the move;
  • return an actionable error explaining that both managed directories must be on the same filesystem;
  • preserve the active thread and database state without partial updates; and
  • surface the specific reason in Desktop instead of only showing a generic failure.

Additional information

This is related to #28868, which discusses symlinked/deep-archive storage and notes that rename-based archive operations are fragile across devices. This report is narrower: the initial archive operation for an otherwise normal Remote SSH thread fails deterministically when the two managed directories are on different filesystems.

Workaround confirmed: removing the separate mount and placing both directories on the same filesystem allowed the native archive operation to complete. The rollout moved from the active tree to the archive tree, and the thread disappeared from the active list.

Privacy note: hostnames, IP addresses, usernames, thread IDs, account details, and private project paths are intentionally omitted.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 26 days ago

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

  • #36289

Powered by Codex Action