›_ Codex Issues
Codex Issues / #38015

Desktop: local pinned threads appear gone after app update when last host was remote SSH

Open 💬 0 comments Opened Aug 11, 2026 by abnershang

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.61601 (ChatGPT macOS desktop / Codex UI)

What subscription do you have?

ChatGPT Pro / Plus (desktop Codex)

What platform is your computer?

Darwin 25.x.x arm64 (macOS)

Also: standalone codex-cli 0.147.0 present on the same machine.

What issue are you seeing?

After updating or relaunching the ChatGPT/Codex desktop app, previously pinned local threads disappear from the sidebar.

The threads are not deleted. On disk they remain:

  • is_pinned = 1 with correct name in ~/.codex/state_5.sqlite (threads table)
  • present in pinned-thread-ids in ~/.codex/.codex-global-state.json

What actually changes is host/project context restored by the app:

  • selected-remote-host-id is restored to a remote SSH-discovered host (not local)
  • selected-project is often a remote project on that host

The sidebar only lists threads for the currently selected host/project, so local pinned threads are filtered out and look like they were wiped by the update.

Switching the host selector back to This Mac / local (or rewriting selected-remote-host-id to local and fully quitting + reopening the app) restores the pins without re-pinning.

This has reproduced multiple times after app updates / relaunches on a multi-host setup (local Mac + remote Mac via Remote SSH / remote control).

No error dialog is shown.

What steps can reproduce the bug?

  1. On Codex desktop (macOS), configure at least two hosts: local and a remote SSH host.
  2. On local, create or open several long-lived operator/work threads and pin them. Confirm they appear under Pins when host = local.
  3. Switch host to the remote machine and optionally select a remote project. Work there so the last-used host/project is remote.
  4. Quit the app fully (or apply a ChatGPT/Codex desktop update and relaunch).
  5. Observe: previously pinned local threads are missing from the sidebar Pins list.
  6. Inspect local state (optional diagnostic):
  • SQLite still has is_pinned=1 for those thread IDs
  • pinned-thread-ids still contains those IDs
  • selected-remote-host-id is the remote host id (e.g. remote-ssh-discovered:<hostname>)
  • selected-project may be { "type": "remote", "projectId": "..." }
  1. Switch host selector to This Mac / local (and a local project if needed).
  2. Observe: the same pins reappear without re-pinning.

What is the expected behavior?

One or more of:

  1. After update/relaunch, do not leave the user in a host context where their primary pinned local threads are invisible without explanation.
  2. If the sidebar is host-scoped, show an explicit empty/filter state, e.g. “N pinned threads on This Mac” / “Pins hidden by host filter,” with a one-click switch to local.
  3. Prefer keeping a global pins section (or cross-host pin indicators) so pin data and pin UX stay aligned.
  4. If host restore to remote is intentional, document it; today it reads as “update deleted my pins.”

Actual behavior

  • Pins appear deleted after desktop update/relaunch.
  • Core pin data remains healthy on disk.
  • Root cause is view filter + restored remote host/project, not pin storage loss.
  • Recovery: switch host to local (or set selected-remote-host-id to local while the app is fully quit, then reopen).

Evidence (neutralized)

When pins looked “gone”:

| Store | Observed |
|--------|----------|
| state_5.sqlite threads.is_pinned | still 1 for all affected threads |
| threads.name | still set (named operator threads) |
| .codex-global-state.json pinned-thread-ids | still listed the same IDs |
| selected-remote-host-id | remote-ssh-discovered:<remote-hostname> |
| selected-project | remote project on that host |

After setting host to local + full quit/reopen: pins visible again.

Paths/hosts in this report are redacted; reproduction only needs multi-host desktop + local pins + last session on remote.

Related issues

Similar multi-host / pin visibility problems (may not be the same root cause):

  • #37310 — pinned conversations disappear after restart (Windows; reappear after pinning another chat)
  • #33579 — desktop hides searchable recent pinned local task
  • #34076 — desktop hides threads while core DB remains healthy
  • #26640 — remote control fetches remote threads but sidebar stays on local (inverse host mismatch)

This report is specifically: local pins hidden because last selected host was remote after app update/relaunch, with pin bits still correct on disk.

Suggested product fix (non-prescriptive)

  • On cold start after update, if pinned-thread-ids includes local threads not visible under the restored host, surface a banner or auto-prefer local for the pins surface.
  • Or split pin list by host and always show local pins when present.
  • Avoid overwriting a user-corrected selected-remote-host-id from in-memory state on quit if the user already switched host in a previous session (secondary race when editing global state while app is open).

Workaround

  1. Host selector → This Mac / local
  2. Or fully quit the app, set selected-remote-host-id to local in ~/.codex/.codex-global-state.json, reopen

Happy to provide redacted diagnostics if useful.

View original on GitHub ↗