Repository navigation
[macOS Desktop] Cloud tasks disappear from sidebar after restart; Dots lists them and direct reads restore individual entries #51675
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 26.1002.52244, build 13536, production channel, confirmed by the built-in app update check on October 7, 2026. The updater reports up_to_date.
What subscription do you have?
Pro, confirmed by the built-in usage-limits response.
What platform is your computer?
macOS on Apple Silicon. uname -mprs:
Darwin 27.0.0 arm64 arm
What issue are you seeing?
After quitting and reopening Desktop, existing cloud/durable tasks are missing from the Codex sidebar's recent task list, while local chats and local automation entries remain visible. The user reports this recurs on relaunch.
Dots still displays the complete cloud task list, according to the user's UI observation. Desktop's built-in list_threads also returns durable-hosted tasks, with no unavailable hosts or sources in the inspected response.
Explicitly calling the built-in read_thread(hostId="durable") for one of the affected tasks succeeds and returns its history. The user then sees only that explicitly read task appear in Desktop's sidebar; the rest do not recover as a group. Desktop screenshots provided during the investigation show the before/after difference. Private screenshots are not attached.
This makes cloud tasks difficult to discover and monitor after restart, even though listing and at least one direct history read still work.
What steps can reproduce the bug?
Observed sequence on the existing account/state; a clean-profile reproducer has not been established:
- Have existing cloud/durable tasks visible in Dots.
- Quit and reopen Codex Desktop.
- Check Desktop's recent-task sidebar: cloud tasks are absent, while local entries remain.
- Confirm the cloud task list remains visible in Dots.
- Run the built-in
list_threads: durable-hosted tasks are returned. - Explicitly read an affected task by ID using the built-in
read_threadwithhostId="durable". - Observe successful history retrieval and that individual task appearing in Desktop's sidebar. Other missing cloud tasks remain absent.
No new test tasks or stress/polling harness were created. Normal Desktop background hydration produced the failures below. A preceding launch did not log the same hydration-denial signature, so this is not claimed to be deterministic on every relaunch.
What is the expected behavior?
Existing cloud tasks accessible to the account should automatically be discoverable in Desktop after restart. If metadata loading fails, show a useful retry/unavailable state and reconcile it on recovery, rather than requiring an explicit per-task tool read to populate the sidebar.
Additional information
Runtime evidence
Observation date: 2026-10-07. All times below are UTC.
For the launch whose first diagnostic entry is 12:26:37.131:
- 12:26:40.681: durable WebSocket initialization succeeds; handshake duration 95 ms.
- 12:26:40.900:
thread/listsucceeds; response duration 218 ms, queue wait 454 ms. - 12:26:43.187–12:28:28.907: 261 distinct failed background read request IDs targeting 29 distinct threads, across two renderers.
- Those failures have
method=thread/read,source=thread_hydration,priority=background,error.code=-32003,error.message="thread access denied", andfailureReason=null. Queue waits are 0–1 ms. - 12:29:34: an explicit built-in direct read of one of those same denied targets succeeds, returning the same ID, host
durable, and one turn of history.
A separate earlier launch at 12:24:55.901 recorded 143 distinct failed read request IDs across the same count of 29 target threads, with the same denial signature. Counts are method-specific request counts, not model turns, user clicks, or unique task counts.
Selected fields from one failure, with identifiers removed:
method=thread/read
source=thread_hydration
priority=background
error={"code":-32003,"message":"thread access denied"}
failureReason=null
durationMs=109
queueWaitMs=0
These observations establish successful listing plus a failing background read path. They do not establish queue saturation, lost cloud data, or why the backend rejects those reads.
Installed-client investigation lead — not a confirmed root cause
Read-only inspection of the installed build found a concrete difference between ordinary metadata reads and explicit shared direct reads:
- The durable transport in
main-B6ZOwXa3.jscan intercept a normalthread/readand perform HTTPGET /v1/threads/{id}with a 30-second timeout. - Its strict params schema does not include
threadAccess. Explicitparams.threadAccess="shared"therefore takes the WebSocket path. - Native catalog/direct-ID reads explicitly use shared access for the durable host.
- Another outgoing-message path can infer shared access and put
threadAccess="shared"on the JSON-RPC top level. The HTTP parser accepts the message but strips that additional top-level field, so inferred shared and explicit shared can select different transports. - A synthetic parser check using the installed schema/library confirmed this selection difference. It is not a trace of the actual failing requests.
- The sidebar metadata query has
retry:1andstaleTime:60000. A lower-level hydration path uses at most two concurrent reads and skips applying a failed result. That skip does not prove deletion of existing entries or explain the entire sidebar outcome.
Please compare the actual failing background request with the successful direct read, including transport, shared-access propagation, account/product context, and subsequent catalog/sidebar reconciliation. The wire payload and server-side authorization decisions have not been captured.
Related reports checked before filing
- #51572 reports repeated access-denied background hydration on Windows. This macOS report adds the missing cloud-sidebar outcome, Dots/listing contrast, same-target successful direct history read, and individual-entry recovery.
- #49121 concerns missing ChatGPT-linked project rows while local projects remain. This report concerns durable task entries, with a different observed read-denial signature.
A shared root cause has not been established; please consolidate if appropriate.
Only sanitized versions, aggregate counts, timing, and selected diagnostic fields are included. No private task IDs/titles, request IDs, account identifiers, home paths, conversation contents, credentials, screenshots, or raw logs are attached. No local database, credentials, settings, or installed-app modifications were made during diagnosis.
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
easyvibecoding commentedon Oct 7, 2026
Additional observation from the user after another restart: cloud task entries briefly appear in Desktop's sidebar, then disappear again. This is more specific than never appearing at all.
In the subsequent captured launch on the same build, October 7, 2026 (UTC):
thread/listsucceeded at 12:48:56.506 (227 ms response, 972 ms queue wait).thread/readfailures began at 12:48:58.429. By the 12:51:52.700 capture cutoff there were 311 distinct failed request IDs across 29 distinct target threads, all with-32003 / thread access deniedandsource=thread_hydration. Queue waits were 0–1 ms.Orbit catalog task metadata could not be loaded; status=undefined.The flash/disappearance is a user-observed UI sequence; no frame capture or correlated UI-state trace establishes exactly when entries disappear relative to these requests.
This points to post-startup refresh/filter/catalog reconciliation as an additional area to inspect. Please trace the transition from initially visible entries to hidden entries, including metadata-query failures. Which branch runs at the moment of disappearance remains unproven. The lower-level hydration skip identified above does not itself prove removal of existing rows.
Read-only follow-up inspection found a more specific client seam in this build:
getInitialSidebarBootstrap().catalogEntriesbefore live catalog loading completes.Orbit catalog task metadata could not be loadedwarning is also present in the cloud sidebar metadata refresh path when hydration throws or expected metadata is incomplete. The catch does not establish deletion of cloud tasks.Possible fix to evaluate: reconcile refresh results per host, retain the last successfully obtained authorized entries for a failed/pending cloud host, and show a source-specific unavailable/retry state. Do not treat another host's successful load as proof that the cloud catalog is complete or replace that cloud host's entries with an empty collection on metadata-read failure. This addresses presentation/recovery while preserving authorization checks; the separate access/transport mismatch still needs investigation.
The bot also suggested #51118. I reviewed it: its detailed diagnostics include failed durable WebSocket handshakes with HTTP 403. This report's captured durable initialization and listing succeed, followed by metadata-read denials and individual recovery through an explicit shared read. A common cause remains possible, but the failure boundary differs; please retain that distinction if consolidating.
No private task identifiers/content, screenshots or raw logs are attached.
easyvibecoding commentedon Oct 7, 2026
This is blocking my ability to work with these tasks. The observed impact also reaches dot’s task read/message integration in ChatGPT Work.
A potentially related dot integration failure occurred during the same investigation on October 7, 2026 (UTC), involving the local investigation task I selected:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID <thread-id> has unsupported placement format version 1.CloudThreadNotFoundError: The cloud thread was not found(NOT_FOUND).This prevented dot from retrieving the investigation results and passing follow-up details to that task. A general ChatGPT Work outage or shared root cause with Desktop’s sidebar hydration failures has not been established.
Please check post-cutover thread ID/placement-format compatibility and task resolution between dot and Codex, and investigate whether other ChatGPT Work task-dependent features are affected. Private task identifiers have been redacted.
AbraxasSH56 commentedon Oct 7, 2026
Additional Windows evidence for this issue (October 7, 2026).
Environment: Windows Codex package 26.1002.7124.0, build 13536; app-server 0.162.0-alpha.2.
Cloud tasks are missing from the Windows sidebar and the iPhone Codex task list, while the web view works. Restarting Windows Codex and switching to Chronological did not help. Backend non-archived task listing succeeds, and saved conversation history remains readable. Both older tasks created on macOS and a newly created Windows diagnostic task are affected.
Windows logs show thread/list succeeding with errorCode=null, followed by background thread/read failures from source=thread_hydration: -32003, “thread access denied”.
Workaround observed on Windows: clicking the official “Open chat” action in the dot conversation restored both the sidebar entry and readable conversation. I repeated this for four affected tasks, and all four recovered individually, each after approximately 10 seconds. These delays are user observations, not measurements derived from log timestamps.
Sanitized log sequence for the new diagnostic task (UTC):
No cache clearing, sign-out or settings changes were performed. Four Windows tasks are now accessible after individual opening. Persistence after restart, automatic recovery of other missing tasks and iPhone recovery remain unverified. The iPhone app version was not recorded.
Could you investigate the difference between background hydration and the explicit “Open chat” route, including authorization context and sidebar refresh? The root cause is not yet established.
easyvibecoding commentedon Oct 7, 2026
Additional observed Desktop build boundary from the same investigation, October 7, 2026. Times are UTC.
thread/readrouted responseserrorCode=nullerrorCode=-32003across 29 distinct targets; 33 additional read responses haveerrorCode=nullAll 29 targets rejected in the second window also had a read response with
errorCode=nullin the previous build's window. Target identity was compared locally; no IDs or response contents are included here. The second window has the previously reportedthread access deniedbackground-hydration signature.Desktop performance logs identify these application build commits:
0333953d9bbe302d8b8abaa2a45312e6723f4fccb157f4341fbf8a9a1f3d0bfc4c79996eb8ae460bNeither commit resolves in the public
openai/codexrepository. Please compare the internal Desktop changes between these builds, especially durable metadata reads/shared-access propagation and bootstrap-to-live catalog reconciliation.This is an observed candidate regression window, not a controlled A/B or bisect. A null routed error code is not a read-back of the full response body or proof of sidebar visibility. Relaunch, application version, client state, and possible service-side changes were not isolated; the local Rust app-server version change is not established as the cause of a durable/cloud failure. The durable service reports 0.1.0 in both windows, which does not identify or rule out a backend deployment change.
Only aggregate counts, version/build identifiers, timestamps, and application build commits are included. No task/request/account IDs, private titles, conversation contents, home paths, credentials, screenshots, or raw logs are attached. No application downgrade or installed-bundle modification was performed.
easyvibecoding commentedon Oct 7, 2026
Downgrade recovery update (October 8, 2026, Asia/Taipei).
On the affected macOS installation:
The user now reports that cloud task visibility has recovered after the downgrade. The installed version/build and the running application path were independently checked locally; sidebar recovery itself is the user's observation.
The downgrade also installed the documented local managed feature policy
in_app_updates = falseto prevent automatic re-upgrading. This policy is present on disk; runtime update-policy enforcement has not yet been independently verified.This is a reported workaround result, not a controlled A/B test or proof of the root cause. Downgrade, relaunch, the update-policy change, and possible service-side changes were not isolated. Persistence across further restarts and recovery of the separate dot read/message integration remain unverified.
easyvibecoding commentedon Oct 7, 2026
Ownership / routing request
@openai/codex-core-agent-team — your team is listed in this repository's CODEOWNERS. Could you help route this app/app-server issue to the Desktop durable transport / sidebar hydration owner?
The observed Desktop build commits are:
0333953d9bbe302d8b8abaa2a45312e6723f4fccb157f4341fbf8a9a1f3d0bfc4c79996eb8ae460bNeither commit resolves in the public repository, so the corresponding internal PRs and authors cannot be identified here. Build 13536 has the documented background-hydration
thread access deniedfailures; the user reports task visibility recovered after downgrading to build 13520, as recorded in the recovery update.Please identify the relevant internal change owner, investigate the changes between these builds, and confirm the Desktop build containing a fix when available. This is a request for investigation ownership; the current evidence does not establish an individual author or a specific commit as the cause.
AbraxasSH56 commentedon Oct 8, 2026
Additional Windows reproduction on version 26.1002.7124.0, build 13536: conversations restored yesterday through “Open chat” disappeared from the sidebar again after reopening the app today.
Logs show connected hosts and no logged error for thread/list, while background thread/read requests with source=thread_hydration return -32003: thread access denied. Explicit navigation through the official app tool successfully reads and resumes the same conversation, with metadata and history ready. Its sidebar item then reappears. Background hydration still reports access denied for that same conversation.
This reproduces a difference between background loading and explicit opening. The underlying cause remains unknown, and the previous sidebar recovery did not persist across reopening the app.
Paul9431 commentedon Oct 8, 2026
Follow-up from Windows package 26.1002.7124.0 after a verified normal quit and relaunch on October 8, 2026 (UTC).
The same existing durable task remained in the supported non-archived task list, with no unavailable hosts, but was missing from the sidebar. The new main process started at 03:29:35Z. Its logs identify background reads for that same target at 03:29:52.971Z and 03:29:53.117Z:
method=thread/read,source=thread_hydration,priority=background,error.code=-32003,error.message="thread access denied",failureReason=null. The signature was still present at 05:49:28.980Z, 05:49:36.698Z and 05:49:44.046Z.Supported explicit navigation to the original task and back restored its sidebar entry. No transcript-read tool, task recreation, cache clearing or database editing was used for this recovery. Persistence across another relaunch was not retested.
A separate Windows execution problem was then tested once through the existing dot: after the approved temporary
windows.sandbox=unelevatedworkaround and full relaunch, a normal sandbox command in the original task returned the requested working directory, Windows OS string and fixed marker, with exit code 0. The command execution and task turn both completed. It did not read or write files.This separates working dot dispatch/local command execution from the failing automatic durable/sidebar hydration path. Local execution recovery should not be interpreted as a persistent fix for this sidebar issue. The server's authorization decision remains unknown. Please compare the background hydration route with successful explicit navigation, including transport and authorization context.
Only sanitized version, timing and diagnostic fields are included; no private task/request/account IDs, titles, paths, conversation contents, credentials, screenshots or raw logs are attached.
Colin-Bao commentedon Oct 8, 2026
Additional macOS reproduction on October 8, 2026, with a repeatable upgrade/rollback sequence.
Submitted in-app feedback ID:
01a1192d-8c72-76e3-842f-8ba84ba5c836Environment: macOS 27.0.1 (26A434), Apple Silicon / arm64. Both versions were run from
/Applications/ChatGPT.appon the same machine.The rollback used the officially signed production archive. Installed version and running app path were checked locally; recovery of the visible list was confirmed by me. Restarting, signing out/back in, and a backed-up cache reset had not resolved the original failure.
In the reproduced 13536 run, the main log contained 676 matching failure entries from 14:33:49 to 14:41:40 UTC+8 on October 8 (06:33:49–06:41:40 UTC). These are log-entry counts, not unique conversations:
Orbit catalog task metadata could not be loadedwas also logged. The adjacent 13520 runs had zerothread access deniedentries and working cloud lists. Each older-build run still had one startup catalog error, so the catalog warning alone is not a reliable indicator of sidebar failure.During the empty-list state, the application's supported direct conversation-read tool could still read an existing cloud conversation. The data remained accessible while automatic list hydration failed.
Potential engineering lead, not a confirmed root cause: static comparison of the installed bundles found that the newer
hydratePinnedThreadspath addsthreadAccess: "shared"for thedurablehost, whereas the older version does not explicitly pass that request option. Please compare the actual background and successful direct-read paths, their transport/authorization context, and sidebar reconciliation. This sequence supports a version-related regression on this installation, but is not a complete isolation of client state or service-side changes.I spent roughly half a day troubleshooting, initially believing my own account or permissions were broken. This disrupted my normal work, and I currently have to remain on the older build. Please investigate and identify the build containing a fix.
I have also escalated this to OpenAI Support and requested additional Codex usage credits or a one-time bank reset / quota reset as compensation for the lost troubleshooting time and work disruption. That compensation request is pending human review; no compensation has been approved.
Only sanitized technical observations and the explicitly submitted feedback ID are included here; no private conversation contents, account identifiers, credentials, or raw logs are attached.
RFinal3 commentedon Oct 8, 2026
Adding another Windows observation from desktop 26.1002.52244 on October 8. A dot-created local task completed successfully but wasn’t initially visible in the sidebar. It was accessible through my dot’s Completed activity, and opening it there added it to the sidebar. Details are in #52231. I haven’t checked for the background-read error signature reported here, so I can confirm the matching UI behavior, not the underlying cause.
Drafted by Luna, my AI assistant, on my behalf and reviewed by me.
rizlah commentedon Oct 9, 2026
i too have noticed this, if i get my dot to give me a link to the task, i can then open that and it apeears in the sidebar only then.
amirtaherkhani commentedon Oct 9, 2026
Additional observation in the ChatGPT desktop app's Codex workspace.
App version
26.1007.21159 (build 20052), verified from installed app metadata.
Operating system
macOS 27.0.1 (build 26A434).
Issue
Existing, unarchived sessions assigned to an expanded custom sidebar section are missing from its visible list. The app's supported sidebar metadata still shows their section membership.
Observed steps
Expected behavior
Existing, unarchived sessions assigned to the section should appear without needing to open each one individually.
This was observed on an existing installation; a clean-install reproducer has not been established. Opening a missing session restored that individual entry. Persistence after restart and a shared root cause with the errors above have not been verified.
najibninaba commentedon Oct 10, 2026
I’m seeing the same sidebar visibility issue on macOS with version 26.1007.21159 (build 20052).
My dot-created tasks still appear under my dot’s Recent activity, and their histories remain accessible, but most are missing from the sidebar’s Recents list. Only one of those tasks currently appears there. Previously, they appeared in both places. The missing tasks are unarchived.
I’ve submitted feedback through the app. Feedback ID: 01a119b5-1b81-70a0-a83b-93f3e2d74006
Sharing it here in case it helps correlate the report with this issue.
nexus-ai-2045 commentedon Oct 10, 2026
Additional macOS build 20052 diagnostics: direct reads succeed while background hydration continues to be denied
Observed on ChatGPT/Codex for macOS, version 26.1007.21159, build 20052. This investigation did not create new test tasks, change settings, clear caches, edit databases, or update/downgrade the application.
The logs from one application launch identify 53 affected threads. Two existing threads were opened through the supported navigation tool. Explicit direct reads against the durable host retrieved history for both of the same thread IDs. Navigation receipts and successful history reads are distinct from independently verified visible UI readiness; the latter was not measured.
During a subsequent 181.18-second observation, background hydration produced 416 denials across the affected set, including eight denials for each of the two comparison threads. Opening those threads individually did not stop the repeated background denials in this observation. This observation overlaps approximately 17.8 seconds of the performance recording described below; the intervals are not independent consecutive experiments or a controlled performance comparison.
A supported performance trace was recorded locally for 91.524 seconds. Logs within that recording interval contain 261 denied requests covering all 53 affected threads:
thread/readthread_hydrationbackground-32003 / thread access deniedThese are failed-request counts, not the sum of both response and failure log entries. A full-log recount also verified that the 181-second observation contains 416 distinct request IDs. The hidden window exists in the startup logs for this launch; it is not attributed to the performance recording.
Read-only inspection of the installed client found an attached-task card path that passes only
hostIdandthreadIdto its metadata query, omittingthreadAccess. A supported durable catalog/direct-reference path explicitly suppliesshared. It has not been established that all 53 logged targets originate from that card path.Other investigation leads are the ordinary HTTP metadata-read path versus an explicit shared WebSocket read, and a branch that derives product SKU
unknownwhen the thread is not loaded in the client. The existing logs and this performance trace did not identify the actual shared-access value, product SKU, or transport of the failed requests. These differences are not asserted to be the root cause.Code inspection also found that access-denied errors are not retained as a terminal stop condition in the same way as thread-not-found errors. The logs establish repeated failures for the same targets, but the exact refresh trigger remains unconfirmed. The performance recording includes JavaScript execution, IPC processing, and garbage collection; it does not isolate CPU cost or user-visible latency for individual denied requests.
Please compare the actual failing background read with the successful direct read for the same thread, including transport selection, shared-access propagation, account/product context, and the server-side authorization decision. Please also investigate why a hidden window hydrates the same threads and what triggers retries after authorization denial.
The configuration file hash differed between the initial snapshot and a later readback, whose file modification time was 17:12 JST. The actor, exact diff, and configuration history during the measurement interval are unknown. This investigator did not edit that file, and the observations are not presented as a configuration-controlled experiment. The hash of the inspected
app.asarremained unchanged.No private thread IDs/titles, conversation contents, account identifiers, local paths, credentials, raw headers, screenshots, or raw traces are included in this comment.
RFinal3 commentedon Oct 10, 2026
Follow-up to my Windows observation above, from October 10, 2026 around 04:48–04:52 UTC.
My dot created a small test task with my connected Windows PC, an existing desktop project, and that project's local repository folder explicitly selected. The task did not initially appear in the left sidebar. After I opened it using View chat, it appeared directly under the intended project. I supplied a screenshot privately that confirmed the placement.
This clarifies the outcome: project placement worked after opening the task; automatic sidebar visibility was still missing. This observation should not be used as evidence that project assignment cannot work. A separate task in that setup successfully ran Git against my local Windows checkout, so local command execution and sidebar discovery should also be kept distinct.
Environment: Windows 11. My most recently checked desktop version was 26.1007.21434; I did not recheck About during this particular test. This was a newly created task, not a controlled restart test.
I have not captured the background-read error signature discussed here, so I cannot confirm a shared root cause. Persistence after restart and mobile visibility were not retested. No private project paths, task identifiers, or screenshots are attached.
Authorship disclosure: Written and posted by Luna, my AI assistant, on my behalf with my permission, using my observations and the test results.
exileskim commentedon Oct 10, 2026
I also have this issue
waleed-salama commentedon Oct 11, 2026
Dot-delegated task using a connected Mac is missing from desktop Recents; pin rolls back
Adding a related macOS observation from October 11, 2026, with failed recovery attempts. This shares the missing-sidebar/direct-read contrast and access-denied signature discussed above. A common root cause is not established. Unlike the original report, a restart trigger and sidebar recovery after direct reading have not been established here.
Environment
com.openai.codex. Version was read from installed app metadata, not the About dialog; correspondence to the currently running window was not independently checked.Observed workflow and impact
The missing entry and brief pin appearance are user-observed. Direct screen inspection during the follow-up investigation was unavailable. This describes one existing affected task, not a fresh-task or clean-profile reproduction.
Verified findings
codexDelegationrecord identifying a source/parent conversation. Private IDs and message contents are omitted.list_threadsandread_threadcalls find the same task and retrieve its history.kind: "codex",hostId: "durable",projectId: null, and a local Mac working directory.pinnedThreads;projectIdremains null. That field alone does not prove loss of host-side project association.codex:thread:local:<redacted-thread-id>. The difference between thislocalkey and the task'sdurablehost is a diagnostic clue, not a proven cause.-32003 thread access denied, alongside a successful read. Supported direct reads also succeed. This is not evidence of lost history or persistent denial of every access path.Failed recovery attempts
move_thread_to_sidebar_section, withhostId: "durable"andsectionId: "pinned"move_thread_to_projectinto an existing local projectprojectId: null.fork_threadwithenvironment.type: "same-directory"Complete raw mutation-error payloads were not available in the retrieved history, so no exact server-side cause is asserted for those failures. The pin behavior may relate to #52305 and #52896.
Investigation lead and limits
Read-only inspection of the installed bundle found ordinary catalog/conversation filters excluding some records with
parentThreadIdorsource.subAgent. The initial delegation record does not prove this task matched those filters. This is a hypothesis only, and may be unrelated to the access-denied path.OpenAI documents Dot profile → Activity for delegated work and cloud-managed tasks using a connected computer. Please clarify whether this task type should appear in Recents and be pinnable, and provide a supported way to preserve access to the original conversation when pinning, project placement and forking fail. If these actions are unsupported for this type, the interface/tools should explain that clearly.
No local database or installed-app edits were made in this investigation. No private chat titles/content, Dot name, personal/account details, thread/parent IDs, local workspace paths, screenshots, credentials or raw logs are included.
Written and posted with AI assistance at the affected user's explicit request.
tokyoganjaman commentedon Oct 12, 2026
Additional macOS reproduction: Cloud child tasks and project mappings are saved, but Desktop hydration is denied (2026-10-12)
Reporting another affected user's observations; private identifiers and paths omitted.
Environment: Apple Silicon, Darwin 27.0.0 / arm64; ChatGPT/Codex Desktop client reported as 26.1007.30912 (running-window build not independently rechecked). Observed October 12, 2026 around 14:08 JST (05:08 UTC).
Retained state vs. visible sidebar
Desktop log evidence
For these same three threads, background requests around October 12 14:08 JST returned:
Supported explicit/direct reads of the affected histories succeed. Request-specific transport, authorization scope, host and threadAccess are not present in the relevant logged failures, so the actual root cause and whether shared access would help remain UNKNOWN. Both durable/websocket and local/stdio occur elsewhere in connection logs, which does not identify the failed request's transport.
Diagnostic implications / request
The old parent-child attachments are intact and the newly created task also gets hydration denials: legacy attachment loss alone does not explain the problem. Please investigate both (1) background hydration denial vs. successful direct read, and (2) saved project association vs. list_threads.projectId=null / Tasks section (possibly related to #53054 and #48728). Comparing the actual failing and successful request authorization context, transport and shared-access propagation would be useful; please provide a supported recovery path preserving history.
No changes were made to existing tasks, source, config, database or cache during this diagnostic. No private thread/account IDs, host/user names, home paths, raw logs or screenshots are included. Separately, Dot reading a user-created Local project thread produced "unsupported placement region 5" (see #49729); a common cause is not asserted.
Submitted by an assistant on the user's explicit request, based on their Mac's diagnostic report.
leosun111 commentedon Oct 13, 2026
Additional macOS evidence on 2026-10-13 for the background hydration issue.
Environment: Apple Silicon; macOS 27.0.1 (26A434); ChatGPT/Codex Desktop 26.1007.30912, build 20156, production channel. The configured updater reported up_to_date earlier the same day.
Observed facts:
Read-only installed-client lead:
Please compare the actual failing hydration and successful direct-read requests, including transport and authorization context, and reconcile retained hidden/unavailable references without deleting user history or weakening access checks. Please provide a supported recovery path and identify the app/service build containing a fix.
No app binaries, databases, cache, account identifiers, security flags or access permissions were changed. No new conversations were created and no messages were sent to affected threads. This follow-up includes no private thread/request/account IDs, titles, paths, conversation contents, credentials, screenshots or raw logs.
shivacyberpunk commentedon Oct 13, 2026
I can reproduce the same visibility problem on macOS as of October 13, 2026. All tasks delegated by my dot to my connected Mac are affected in my setup.
Observed sequence:
The same delegated tasks are also absent from Codex/Remote on my iPhone, as reported in #49848. This makes it difficult to find and monitor delegated work without keeping individual links.
Exact desktop/mobile build numbers have not been verified for this report. I have not confirmed the background-read error signature discussed above, so I cannot establish a shared root cause.
Is there a supported workaround that survives restart, or an app/service version with a confirmed fix?
k-app-2025 commentedon Oct 14, 2026
Additional user-reported macOS observation, October 14, 2026:
codex://threads/<thread-id>link supplied by their dot makes that chat visible again.Expected behavior: existing chats should remain discoverable in their project lists across restarts without reopening individual deep links.
This report describes the affected user's observations, not an independent reproduction by the submitting assistant. The exact desktop build and macOS version have not been collected. Local-versus-cloud hosting of all affected chats has not been verified. No logs were collected, so the background-read error signature and shared root cause discussed above are unconfirmed; actual data loss has not been established.
Adding this here because the restart/direct-opening visibility pattern matches this issue. Please advise if the broader project-list symptom belongs in a separate report, and identify a supported recovery or fixed build when available.
Submitted by an assistant with the affected user's permission. No private chat content, project names, filesystem paths, thread/account identifiers, or screenshots are included.
EmilioEsposito commentedon Oct 14, 2026
I am seeing this on macOS as of October 14, 2026, specifically with local threads that Dot successfully creates and runs on my laptop:
Pinning overlaps #52305, and the labeling issue overlaps #51197.
These are Dot-created local threads. Separately, Dot cannot read local threads I create outside Dot, reported at #52873 (comment) . I have not established whether the two cases share a cause.
reliable-ly0411 commentedon Oct 15, 2026
Windows follow-up: ordinary reads succeed, explicit shared reads deny the same owned Dot child (2026-10-15)
Observed on the running Windows package 26.1007.9446.0, app package.json version 26.1007.71326, build 20398 (prod), bundled app-server 0.162.0-alpha.17.2. The installed app was inspected read-only; no executable, archive, feature/security gate, credential, or conversation was modified.
For one existing non-archived Dot-managed task, bounded metadata-only requests over one authenticated connection to the official cloud backend returned:
The client contains a matching static path:
The current process log contains 1,807 denied background thread/read events, including 146 for this exact task, from the October 14 startup through October 15 07:58:49 Asia/Shanghai. These are log events, not billed/model requests or unique conversations. Orbit catalog metadata warnings also recur. The original task appears in the official web sidebar and Dot recent activity, where its status is unavailable. The visibility flag itself was not independently retrieved.
Please compare the actual Desktop background request with the successful ordinary request, including authorization mode and transport. Evaluate owner-aware catalog hydration: load owned Dot tasks using their valid ordinary access path while retaining explicit shared access for genuinely shared tasks. Preserve server authorization checks, and retain the last valid authorized catalog per host when refresh fails. Please identify the signed Windows app/service build with the fix.
The test is an independent same-task protocol comparison plus installed-code reproduction, not a packet capture of the Desktop UI request. Native sidebar recovery across restart has not been verified. No private IDs, titles, contents, account identifiers, filesystem paths, tokens, raw logs, or screenshots are included.
Posted with AI assistance and the affected user's explicit authorization.