Codex Desktop hides a searchable recent pinned local task from default and pinned task lists

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

• #33508
• #33396

Powered by Codex Action

+1

I can confirm this as a recurring multi-thread pin/sidebar hydration failure on macOS.

Environment

• Codex/ChatGPT Desktop: 26.715.21425 (build 5488)
• Bundled CLI: codex-cli 0.145.0-alpha.18
• macOS: 27.0 developer beta (26A5368g)
• Architecture: Apple Silicon / arm64

Current recurrence

The Desktop sidebar displays only 9 pinned threads, while the durable local state contains 22 unique pinned thread IDs.

Host-side verification:

• ~/.codex/.codex-global-state.json: 22 unique pinned thread IDs
• ~/.codex/state_5.sqlite: all 22 thread rows exist
• Archived pinned threads: 0
• Missing pinned database rows: 0
• All 22 use history_mode=legacy
• PRAGMA quick_check: ok

This has occurred at least twice:

• July 11: 21 stored pins, with 13 missing from the sidebar
• July 17: 22 stored pins, with the same count of 13 missing from the sidebar

Supported recovery attempt

After backing up the state, I cycled only the 13 hidden threads through the supported pin control:

1. Unpin the 13 hidden IDs
2. Verify the pin list dropped from 22 to 9
3. Re-pin those same IDs in their original order
4. Verify the durable list returned to the original 22 IDs and order

No SQLite rows were edited.

During the re-pin operation, the Desktop log emitted exactly 13 warnings—one for every hidden pin:

Failed to refresh thread description: No Codex thread found for threadId: <redacted>

The pin API reported success and the durable pin state was correct, but the Desktop UI later continued to display only the same 9 pins after an app relaunch.

Expected behavior

Every ID in the durable pinned-thread list that still has an unarchived, readable thread row should appear in the pinned sidebar. Restarting or relaunching Desktop should not return the sidebar to a partial subset.

Impact

This makes existing work appear deleted even though the threads remain healthy locally. Repeatedly cycling pin state is not a durable workaround and can obscure the underlying reproduction.

This appears closely related to #17253 and other reports where local thread state remains intact while Desktop enumeration and sidebar hydration diverge.

Additional reproduction: pin exists locally, sidebar rehydrates after pinning another task

I reproduced a closely related failure again on July 21, 2026 with a different local task.

Environment

• ChatGPT/Codex desktop app version: 26.715.70719
• macOS: 27.0 (26A5368g)
• Architecture: Apple Silicon / arm64

Affected task

• Title: OS - Family
• Thread ID: 019eaa4f-79b3-7bc0-9118-0c7fc5f0fea8
• Host: local
• Status returned by targeted search: notLoaded

Diagnostics and observed behavior

1. The task was absent from the visible pinned sidebar, leading me to believe it had disappeared.
2. list_threads(query="OS - Family") returned no results.
3. A broader list_threads(query="family") search returned the task with the correct ID/title and status: notLoaded.
4. The local global-state file still contained the thread ID in pinned-thread-ids:

• total pin count: 21
• affected thread ID present: true

1. Cycling the supported pin control (pinned=false, then pinned=true) returned success for both operations.
2. The most visible recovery occurred when I manually pinned a different thread in the desktop UI: the missing OS - Family pin then appeared again.

Interpretation

This provides additional evidence that the underlying thread and pin record are intact and that the failure is in sidebar/list hydration or refresh. It may also indicate that:

• status: notLoaded contributes to exclusion from normal/pinned listings;
• exact-title and broad-term search use different matching/index paths; and
• a pin-state mutation on any thread can invalidate/rebuild the sidebar state and make previously hidden pins visible again.

No direct database editing was performed.

July 24 recurrence: current active task is pinned in API state but absent from sidebar

The failure reproduced again on July 24, 2026, this time with the task that was currently open and active.

Confirmed state

A read-only list_threads(limit=30) call returned:

• schemaVersion: 4
• 27 entries in pinnedThreads
• affected task present in pinnedThreads
• pinnedIndex: 27
• task status: active
• host: local
• task kind: codex

Despite that, the newly pinned task did not appear in the desktop pinned sidebar.

This is useful additional evidence because the affected task was not notLoaded in this reproduction. The omission can therefore affect a currently active, readable task whose pin is already present in the app's own thread-list response.

Crash / recovery behavior

I did not cycle the pin during this reproduction. Previous supported recovery attempts had unpinned and re-pinned hidden tasks, and the user now reports that asking Codex to repair the missing pins can cause the desktop app to crash.

I do not currently have a crash log proving which internal operation triggers the crash, so this should be treated as an observed correlation rather than a confirmed cause. Given that the durable/API-visible pin was already correct, repeated bulk pin mutations were intentionally avoided.

Updated interpretation

The failure now appears to be a divergence between:

1. the authoritative pinnedThreads collection returned by the app;
2. the sidebar's rendered subset; and
3. sidebar invalidation/rehydration behavior after pin mutations.

It is not limited to missing database rows, archived threads, or status: notLoaded tasks. A safe diagnostic or “reload pinned sidebar from authoritative state” action would be preferable to using repeated unpin/re-pin mutations as a workaround.

July 28 recurrence on 26.721.41059: active local pin is present in list_threads but absent from Desktop sidebar

I can reproduce the same failure on a newer Desktop build, with a useful remote-control trigger/state distinction.

Environment

• Codex/ChatGPT Desktop: 26.721.41059 (build 5848)
• Bundled CLI: codex-cli 0.146.0-alpha.3.1
• macOS: 26.5.2 (25F84)
• Architecture: Apple Silicon / arm64

Confirmed backend state

A read-only list_threads(limit=10) call returned schemaVersion: 4 and exactly two pinnedThreads after stale pins were removed:

1. a currently active thread on a paired Remote Control host (pinnedIndex: 1)
2. the affected currently active local thread (hostId: local, status: active, pinnedIndex: 2)

The affected local thread has a non-empty title, summary, cwd, and recent updatedAt. Direct navigation to the thread succeeds, and the conversation remains fully usable once opened.

Despite that, the affected local task is absent from the visible Local sidebar.

Recovery attempts that did not work

• renamed the affected thread
• pinned it through the supported thread API
• performed a real unpin → pin transition
• removed two stale notLoaded ghost pins so only the two valid active pins remained
• navigated directly back to the affected thread

After every step, list_threads continued to return the affected local thread under pinnedThreads, but Desktop still did not render it in the Local sidebar.

Additional trigger/context

This occurred while pairing and switching to a Linux Remote Control host. The remote task and local task coexist correctly in the backend response, but the local sidebar does not reconcile the local task afterward. This suggests the client-side connection/host filter or sidebar cache can diverge from the authoritative pinnedThreads response; it is not limited to notLoaded threads, stale DB rows, or failed pin persistence.

Expected invariant

For the selected host, every readable, unarchived thread returned by the app's own thread index as status: active, hostId: local, and a valid pinnedIndex should be rendered in the pinned/local sidebar without requiring a restart or unrelated pin mutation.

I can reproduce the same failure on a newly created local project task, with one additional deterministic trigger: the affected task was created from another task through the official cross-task creation flow and displayed the banner “Sent by ChatGPT from another task”.

Environment

• ChatGPT Desktop: 26.818.41509 (build 6962)
• macOS: 26.4.1 (build 25E253)
• Architecture: Apple Silicon / arm64
• Observed: 2026-08-25

Reproduction

1. From an existing task, create a new task in a saved local project through the official thread-creation flow.
2. Open the created task. It is visible in the sidebar and shows “Sent by ChatGPT from another task”.
3. Click Pin chat in the sidebar.
4. Observe that nothing changes.
5. Call the thread pin operation directly for the same task.
6. The operation reports success:

``json
{"pinned": true}
``

1. Immediately read the normal thread inventory.
2. The affected task is absent from both pinnedThreads and the ordinary threads result, even though direct thread read and task navigation still work.

Additional checks

• This is not a global pin failure: other existing tasks pin normally in the same app/account.
• Reproduced while the affected task was actively working.
• Reproduced again after the task completed and became idle.
• Reapplying the exact same title did not refresh the index.
• Archive → restore succeeded but did not repair the listing.
• Re-pinning after archive → restore again reported success, but the task was still absent from both pinned and ordinary inventory.
• The local session index contains the affected task.
• Direct thread read confirms the completed content is intact.
• The task was created for a saved project, but direct thread metadata reported an unexpected root cwd (/), suggesting that cross-task creation may fail to persist or hydrate the normal project/sidebar association.

The affected title, project path, task ID, and screenshots are omitted because they contain customer/workspace information. I can provide sanitized identifiers or logs privately if maintainers need them.

Expected behavior

A task created from another task should be a normal peer in sidebar/index behavior. Pinning should persist and place it in pinnedThreads, regardless of whether it is active or idle. If pinning fails, the operation should return an error instead of reporting pinned: true.

A Windows recurrence confirms that the authoritative task inventory and the rendered sidebar can remain divergent even after a cross-host identity collision is removed.

Environment

• Codex Desktop 26.820.7780.0
• Windows on ARM64
• Bundled/local CLI 0.149.1
• One connected Linux Remote SSH host

Authoritative state after recovery

A fresh list_threads(limit=20) call returns the affected task under pinnedThreads with all of the following:

• hostId: local
• status: active
• pinnedIndex: 1
• a non-empty title, summary, cwd, project ID, and recent updatedAt

Additional read-only checks show:

• the active Desktop catalog contains the readable, unarchived local row;
• the global state contains the task in the unified sidebar pinned order;
• it is also present in the app-server pinned order and the pinned-ID list;
• its project assignment and project thread order are present;
• the assigned local project exists and is currently selected.

Despite this, the task is absent from the visible Desktop sidebar. Direct navigation from another task opens the correct task, and the task can continue normally. After navigating away, it is still not discoverable from the sidebar.

Trigger and boundary

The task previously had a stale Remote SSH object with the same thread_id, related to #38927. Archiving only that exact remote object repaired hostless navigation: the current local object became the first pinned item in the task API. It did not repair the rendered sidebar.

Before the remote object was archived, Desktop logs showed sidebar workspace metadata requests attempting to resolve a Windows cwd through the Remote SSH host. Those requests failed with:

Invalid request: AbsolutePathBuf deserialized without a base path

After archival, owner routing changed to the local host, but the sidebar did not rehydrate from the corrected task and pin state.

No rollout, database row, or global-state entry was edited. The task content remains intact.

Expected behavior

• Every readable local task returned in pinnedThreads with pinnedIndex: 1 must render in the selected local project's sidebar.
• A host change or duplicate removal must invalidate stale sidebar workspace metadata.
• Direct navigation must not be the only way to recover an otherwise healthy pinned task.
• The renderer should reconcile from the authoritative task inventory instead of retaining a stale host-filtered projection.

This appears to be the sidebar-hydration phase that remains after the separate cross-host collision is resolved. Private identifiers, task content, project names, paths, addresses, and hostnames are omitted.