Codex Desktop loses pinned remote-root sessions after macOS sleep/wake (thread not loaded)

What version of the Codex App are you using?

Codex Desktop 26.527.60818 (3437), bundle id com.openai.codex.

What subscription do you have?

Not specified in this public report. I can provide account/subscription details privately if needed.

What platform is your computer?

Local machine:

• macOS 26.6
• Build 25G5028f
• Architecture: arm64

Remote environment:

• Codex Desktop connects to a Linux SSH remote.
• The affected sessions exist only in the remote root-scoped Codex home, e.g. /data/codex/users/root/.codex.
• The same thread IDs do not exist in the normal-user remote Codex home, e.g. /data/codex/users/<user>/.codex.
• Desktop has both a managed root remote host identity and a discovered/non-root remote host identity for the same remote machine/work area.

What issue are you seeing?

Codex Desktop loses or fails to rehydrate pinned remote-root sessions after the Mac laptop sleeps/wakes from lid close/open.

The sessions are not lost remotely. Remote inspection confirms the affected threads still exist in the root-scoped remote state_5.sqlite, are archived = 0, and have rollout JSONL files present under the root-scoped Codex home. The same IDs are absent from the normal-user remote state_5.sqlite, which makes this a root/user scope case rather than generic remote data loss.

The Desktop/client view is what loses the pinned session. After wake/reconnect, the pinned item disappears or cannot be opened from Desktop, while the thread remains recoverable from the remote root Codex home with an explicit root CODEX_HOME and codex resume.

Steps to reproduce

1. Open Codex Desktop on macOS.
2. Connect to a remote Linux host over SSH where Desktop can see both a normal-user remote scope and a managed root/admin remote scope.
3. Start or resume a thread that exists only under the root-scoped remote Codex home, for example:

``sh
CODEX_HOME=/data/codex/users/root/.codex codex resume --all <thread-id>
``

1. Pin that remote-root thread in Codex Desktop.
2. Close the Mac laptop lid long enough to produce clamshell sleep, then reopen/wake.
3. Let Desktop reconnect/recover remote app-server/websocket state.
4. Check the pinned/recent/sidebar thread list.

Expected behavior

Pinned remote threads should survive sleep/wake and reconnect.

For remote threads, the pin should be persisted and rehydrated as a fully scoped reference, not just a bare thread ID. At minimum the pin/hydration path should preserve:

• thread_id
• remote host identity / hostId
• remote user/scope, e.g. root vs normal user
• effective remote CODEX_HOME
• remote cwd/project path

If the remote host is temporarily unavailable after wake, Desktop should keep a stale/reconnectable pinned item and show a reconnect message instead of silently hiding/dropping the pin.

Actual behavior

After sleep/wake, Desktop attempts to hydrate the pinned thread but fails with thread not loaded. The pinned session then disappears from the Desktop/client view, even though the remote root session still exists and is unarchived.

Local Desktop evidence:

• ~/.codex/state_5.sqlite has 0 rows in threads for the affected remote-root session IDs.
• ~/.codex/state_5.sqlite has 0 rows in remote_control_enrollments.
• ~/.codex/.codex-global-state.json still has per-thread permission residue for the affected IDs.
• One affected ID was still present in unread state under the managed root remote host identity.
• No obvious durable pinned / pin table or column was found locally or in the remote state DBs.
• Desktop logs repeatedly show pinned hydration failures, including messages equivalent to:

``text
thread not loaded
Failed to read pinned thread
``

• Around reconnect, logs also show a host/scope split: the discovered/non-root remote host reports that the current conversation does not exist on the target host, while the managed root remote host can successfully read/resume some of the same root-only sessions.

Remote evidence:

• The root-scoped remote state_5.sqlite contains the affected threads with archived = 0.
• Their rollout JSONL files exist under the root-scoped remote sessions/YYYY/MM/DD/ tree.
• No matching rollout files were found in archived_sessions.
• The normal-user remote state_5.sqlite does not contain the affected IDs.
• A parent root-gate thread's sidecar/subagent tree remains intact in thread_spawn_edges; child threads are closed, archived = 0, and present.

Sleep/wake correlation from pmset -g log:

• 2026-06-01 13:31:45 -0700: clamshell sleep.
• 2026-06-01 13:33:17 -0700: full wake.
• Desktop reconnect/recovery and pinned hydration failures occur around 2026-06-01T20:33Z to 20:35Z, within roughly 0-2 minutes of wake.

Why this looks like a Desktop/client bug

This does not appear to be remote session deletion or archival. The remote root session store remains intact and resumable.

The likely failure mode is that Desktop stores or rehydrates pinned remote threads without enough remote scope information. After sleep/wake, it appears to resolve a pinned root-only thread through an unloaded or wrong host/user scope, producing thread not loaded and removing/hiding the pinned thread from the Desktop view.

A robust product fix would make pinned remote sessions scoped by remote host identity and effective remote Codex home, and would avoid dropping pins when a reconnect/hydration attempt temporarily fails.

Related issues

This is related to, but slightly narrower than, existing remote/sidebar/session hydration issues:

• #22438: remote SSH persisted sessions not shown after restart
• #20399: remote project/thread host state can mix across SSH host scopes
• #22806: remote sidebar/pinned chat sync issues on mobile

This report adds a specific pinned remote-root + macOS sleep/wake reproduction with evidence that the remote root DB is intact while Desktop pinned hydration fails with thread not loaded.

Privacy note

Exact thread IDs, raw logs, usernames, and private project path segments are intentionally redacted from this public issue. I can provide exact redacted excerpts or additional diagnostics privately if OpenAI maintainers need them.