Repository navigation
[Desktop] Cloud chat pin immediately reverts; sidebar tool reports it could not be moved into Pinned #52896
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Not collected. This report concerns the desktop app; the cloud runtime version is not being substituted for the desktop app version.
What subscription do you have?
Not collected.
What platform is your computer?
Codex desktop app. Desktop OS and OS version were not collected.
What issue are you seeing?
An existing cloud-backed Codex chat cannot be kept individually pinned. The user reports that choosing Pin briefly moves the chat into Pinned, then it immediately returns to its original sidebar section.
Two attempts through the app's move_thread_to_sidebar_section tool also failed with the exact response:
The task could not be moved into the pinned section.
Fresh list_threads checks after the attempts returned the affected chat in threads, absent from pinnedThreads.
The containing project is pinned, but the chat itself remains unpinned. Other cloud-backed chats already appear in Pinned in the same sidebar.
What steps can reproduce the bug?
Observed on an existing affected chat; this has not been reduced to a clean-account reproduction.
- Find an existing cloud-backed Codex chat belonging to a pinned project.
- Choose Pin in the desktop sidebar.
- The user reports that the chat briefly enters Pinned, then immediately returns to its original section.
- Separately, list chats through the app tools and confirm the affected chat is returned as unpinned, with
hostId: "durable"andstatus: "active". - Call
move_thread_to_sidebar_sectionwith the returned chat ID,source: "codex",sectionId: "pinned", andhostId: "durable". - The tool returns the error quoted above. A fresh list confirms the chat remains unpinned.
- Retry the same move while omitting the optional
hostId. The same error occurs, and a subsequent list again confirms the chat remains unpinned.
What is the expected behavior?
Pinning an accessible chat should leave it individually pinned. If pinning cannot be completed, the app should show a useful explanation rather than briefly moving the chat and then reverting it.
Additional information
- Observed October 10, 2026.
- Sidebar grouping was by project; chat and pinned sorting were
updated_at. - The chat was active during the tool checks. Whether activity, project membership, or cloud backing contributes to the failure is unknown.
- The visual bounce-back is user-reported. The tool failures and readbacks were directly observed by the assistant. A shared underlying cause has not been established.
- Related: [macOS][Dots] Dot-initiated chats show “Pin chat” but remain unpinned #52305 describes pinning failures for Dot-initiated chats; [macOS] Pinning a searchable ChatGPT project conversation does not add it to Codex sidebar #52510 describes a searchable ChatGPT project conversation not appearing in Pinned. This report concerns a cloud-backed Codex chat, and no shared cause is asserted.
- No desktop logs, screen recording, or in-app feedback ID were collected.
- Private chat titles, project names, thread IDs, and conversation content are omitted.
Submitted by an AI assistant at the user's request.
Activity
github-actions commentedon Oct 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
CashGush commentedon Oct 19, 2026
Additional user-authorized diagnostic evidence from a macOS desktop installation, observed 2026-10-19. Desktop app version/build was not collected; the cloud runtime version is not being substituted for it.
The exact native operation still fails for an existing cloud-backed Codex conversation:
A fresh supported
list_threadsread returns the target withhostId:"durable", butpinnedThreadsremains empty. Explicit-host attempts have also returned a durable-host lookup failure, while the default route reaches the quoted pin failure. Custom-section placement, title updates, and ordinary history reads work.New distinction from the original report: the pin failure persists after the conversation is idle. The last user-requested diagnostic turn had been stuck in progress. One controlled archive/unarchive cycle changed that turn to
interrupted; a subsequent independent read returned thread statusidle. A new pin attempt still failed. Thus a running turn alone is not sufficient to explain this reproduction.The archive cycle also produced a false-negative reload result (
Unarchived conversation [redacted] could not be loaded). Subsequent ordinary history reads succeeded, the original was absent from the complete archived list, and the full set of archived IDs returned exactly to its prior value. This is evidence of restored archive state and a cleared stale turn, not proof that terminal execution or desktop rendering was repaired.Before that cycle, three saved custom-section memberships were returned by the supported tool, while the user reported seeing only two entries. This resembles the broad-list versus UI-hydration contrast in #52129, but no owner/shared WebSocket A/B test or desktop log capture was available on this installation. A common access-mode cause is not established.
Pinned sorting was already
manual; the workaround in #54557 therefore does not resolve this reproduction. A full application quit/reopen restored a previously disconnected app-management channel but did not fix pinning. No installed binary, authentication store, local conversation database, network policy, or access control was patched or reset.Please identify a supported client/service correction or recovery procedure for individually pinning an owned durable conversation. If this is related to owner-versus-shared hydration, please provide an owner-aware path that preserves existing access controls and original history. A useful acceptance check is successful pin response plus inclusion in a fresh pinned list and persistence after an ordinary restart.
Submitted by an AI assistant at the user's explicit request to engage technical specialists/developers. This update deliberately excludes private conversation/account/request IDs, titles, project/repository details, paths, credentials, conversation contents, screenshots, and raw logs. No client fix is claimed.