Feature request: host-local Codex daemons with shared session history and safe cross-node resume #52050

Summary

Please support independent Codex managed app-server/background daemons on Linux hosts that share network-mounted storage, while providing unified session history and safe cross-host session resumption.

This would help users working across multiple machines with separate runtime environments but shared project storage.

Use case

• Multiple Linux hosts independently run Codex CLI and managed background daemons.
• The hosts access common, network-mounted home and/or project storage.
• A user wants to find, read, and later continue a Codex conversation from a different host, without depending on the original host's daemon remaining reachable.

The intended model is one independent daemon per host, with shared access to durable conversation history.

Problem

Using the same CODEX_HOME on independent hosts can cause host-local daemon state—such as process IDs, Unix sockets, locks, and mutable runtime files—to be treated as if it belonged to one machine.

Using a separate CODEX_HOME per host improves daemon isolation, but splits session history, indexes, and metadata. Sessions created on one host are no longer reliably discoverable or resumable from another.

Users therefore lack a supported way to combine safe host-local daemon operation with cross-host session continuity.

Requested behavior

1. Host-local daemon state. Run an independent managed daemon on each host, with appropriately scoped sockets, PIDs, locks, and other transient runtime state. A socket pathname on shared storage must not be mistaken for a reachable local daemon on another host.
2. Unified session discovery and read access. Provide a supported way, such as codex resume --all or an equivalent interface, to discover and read conversation history from other hosts. Show origin/ownership information where relevant.
3. Safe cross-host resume. Allow an idle or completed conversation to be resumed on another host while preserving its conversational context, subject to workspace availability and path validation/remapping.
4. Single-writer protection and explicit ownership. Prevent concurrent writers from modifying the same conversation on different hosts. Expose current ownership and provide safe handoff when possible, or a clear error while the original session remains active.
5. First-class storage separation. Support a configuration that separates host-specific daemon/runtime state from shared durable session history and indexes, with suitable coordination for network filesystems. Users should not need unsupported symlinks or manual copying of JSONL/SQLite files.

Acceptance scenario

1. Start separate Codex daemons on two hosts that can access the same project storage.
2. Create and finish a conversation on host A.
3. On host B, discover the conversation, inspect its history, and resume it safely through host B's daemon.
4. If the conversation is still active on one host, a competing resume on another host is prevented without corrupting or silently forking the session.

Preserving conversation history and enabling safe idle-session handoff is the priority. Migrating live processes, shells, or running commands is outside the scope of this request.

Related issues

• Remote connections can mix project/thread host state when SSH hosts share HOME #20399 — Remote connections can mix project/thread host state when SSH hosts share HOME.
• Codex Desktop Remote SSH reconnect loop leaks thousands of orphaned app-server processes when hosts share an NFS home #35217 — Codex Desktop Remote SSH reconnect loop leaks orphaned app-server processes when hosts share an NFS home.

These reports concern related host-identity and lifecycle failures. This request focuses on the complementary capability: host-local daemon isolation without losing cross-host session continuity.