[Windows Desktop] Dot-created cloud history remains missing/access-denied after connection recovery; direct reads retrieve original messages

Codex App version

Windows package OpenAI.Codex 26.1002.7124.0, verified locally on October 8, 2026. Installed desktop build: 13536. Subscription and exact Windows build were not collected for this report.

Problem

Previously created dot/cloud conversations remain missing or cannot load in the Windows desktop sidebar after the durable connection recovered. The user confirmed the dot entry returned and continuous reconnecting stopped, but only two of six known cloud conversations were visible in a custom sidebar section. The same six original IDs are returned by the built-in task listing.

This report concerns original cloud conversations on host durable, not new local conversations. Permanent deletion has not been established.

Observed sequence

The installation previously had a network/connection outage. After recovery, the user confirmed dot stopped continuously reconnecting.
Six original cloud conversations were identified by the built-in list_threads.
An authorized custom sidebar section was created and the six original IDs assigned. API membership persisted, but the user's screenshot showed only one entry initially and two subsequently.
Opening an affected cloud conversation with a thread-ID-only navigation API attempted local resume and produced:
```
-32600 no rollout found for thread id [redacted]
```
This was an incorrect local navigation path and is not evidence of lost cloud history.
A supported installed-client deep link carrying hostId=durable&threadAccess=shared was then tested for another affected conversation. Logs confirmed durable selection, but thread/read and thread/turns/list still failed:
```
-32003 thread access denied
```
Subsequent built-in read_thread(hostId="durable") calls successfully retrieved original user/assistant messages for three older conversations. Their returned pages reported hasMore=false. Another affected conversation's direct read failed with the durable host unavailable/failed.
A later list_threads response still returned all six original cloud IDs and reported no unavailable hosts or sources.

This is an observed existing-profile sequence; a clean-install reproducer has not been established. Successful listing, direct reading, UI hydration, and actual sidebar visibility must be distinguished.

Selected diagnostic timing

October 8, 2026, UTC+8:

21:50:37: thread-ID-only local resume failed with no rollout found.
21:52:27: explicit durable navigation logged maybe_resume_started hostId=durable.
21:52:28: that cloud conversation's UI thread/read and thread/turns/list failed with thread access denied.

Background hydration also recorded method=thread/read, source=thread_hydration, priority=background, error code -32003.

Expected behavior / requested investigation

Authorized original cloud conversations should load and remain discoverable in Desktop. Persisting sidebar membership should not silently omit entries whose hydration fails. Please compare native explicit durable/shared reads with UI hydration and resume, including transport selection, shared-access propagation, account/product context, and reconciliation into the sidebar.

Please also provide a supported recovery procedure that preserves original history and active work without deleting app data or restarting working network infrastructure.

Investigation lead, not a confirmed root cause

Read-only inspection of the installed client found ordinary thread/read can be intercepted by an HTTP transport, while explicit shared params are handled differently by its strict schema and may select the WebSocket path. This resembles the lead in #51675. Actual failing wire payloads/server authorization decisions were not captured, so neither this mechanism nor a common root cause is established.

Diagnostic interventions and limits

A custom sidebar section and original-conversation navigation were used during diagnosis. No installed application bundle, credential store, server ACL, conversation database, or original cloud messages were modified. No new replacement conversations or task messages were created. A local view-only copy of retrievable messages was saved as a temporary workaround; it did not repair Desktop loading.

The preceding connection outage and this history-loading failure have not been proven to share a root cause. This report does not include private local network configuration.

Related reports

[macOS Desktop] Cloud tasks disappear from sidebar after restart; Dots lists them and direct reads restore individual entries #51675: macOS cloud-task disappearance and direct-read/UI-hydration contrast.
[Windows Desktop] Background hydration repeatedly reads access-denied conversations after restart #51572: Windows access-denied background hydration.
[Windows Desktop] Cloud tasks disappear again after restart; task coordination later fails with active-Aeon error #51740: Windows cloud tasks disappearing again after restart, with a separate coordination error.

Please consolidate if appropriate. This report adds the current Windows connection-recovered state, persisted six-member section with only two UI entries, explicit durable/shared navigation still denied, and fresh retrieval of three original histories.

Only sanitized errors, version, timings, counts, and observations are included. No private thread IDs/titles, account details, project names, local paths, screenshots, credentials, raw logs, or conversation contents are attached.

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

[macOS Desktop] Cloud tasks disappear from sidebar after restart; Dots lists them and direct reads restore individual entries #51675
[Windows Desktop] Cloud tasks disappear again after restart; task coordination later fails with active-Aeon error #51740
[Windows Desktop] Background hydration repeatedly reads access-denied conversations after restart #51572
"Cloud" conversations no longer connected and removed from Codex #51118

Powered by Codex Action

Follow-up from the reporter: the original missing-cloud-conversation symptom has recurred. The desktop custom task section is empty again. The reporter also says the application window disappeared after some time despite not intentionally closing Codex. A shared cause between window disappearance and the cloud-sidebar failure is unconfirmed. The problem remains unresolved; please provide a supported recovery that preserves original history. No new private diagnostics, screenshots, task identifiers, account information, or network details are included in this update.

Another Windows user is experiencing this issue: tasks delegated through Dot have not appeared reliably in recent items for an extended period, making it difficult to locate tasks and follow their progress.

Please prioritize a fix and provide a supported recovery method that preserves existing conversations and tasks. Please also identify the Windows release or service update containing the fix when available.

Submitted by Codex with the user's authorization.

Updated 2026-10-16: read-only A/B tests now isolate an access-mode mismatch for two affected Dot child tasks.

Symptom and environment

After Desktop restarts, the custom sidebar group remains but these original task entries disappear. The user must open them through Dot first. Re-adding a group only restores visibility for the current session.

Installed Electron package metadata: 26.1013.31256.
Windows MSIX package: 26.1013.3656.0.
Bundled running CLI: 0.163.0-alpha.10.2.
Windows 11 25H2, build 26200.9711.
Saved custom-section membership and the durable host mapping are present on disk.
Both original tasks remain accessible and continue their work. The successful metadata responses identify both as threadSource="aeon_child".

Controlled live result: ordinary -> shared -> ordinary

A fresh WebSocket used the existing signed-in account, the normal Desktop protocol, normal TLS validation, and one connection for the following reads. Only metadata was requested; no model turn, task message, or file operation was started.

For each unchanged target ID, only the threadAccess parameter changed:

Target	Request	Result
A	thread/read, includeTurns=false, no threadAccess	Correct target metadata returned
A	Same request + threadAccess="shared"	-32003, "thread access denied"
A	Same request, threadAccess removed again	Correct target metadata returned
B	thread/read, includeTurns=false, no threadAccess	Correct target metadata returned
B	Same request + threadAccess="shared"	-32003, "thread access denied"
B	Same request, threadAccess removed again	Correct target metadata returned

UTC interval: 2026-10-16T07:36:28.709Z through 07:36:30.829Z. Per-request durations: 313-375 ms. Returned metadata contained zero turns.

A separate same-account HTTP control to /v1/threads/[target] also returned HTTP 200 and the correct target metadata with product SKU unknown, codex, and aeon, and with threadAccess=shared in the query. Thus neither a general loss of access nor the HTTP product-SKU choice reproduced the rejection. The WebSocket shared-access parameter did.

The initial independent HTTP attempt without the existing local proxy path timed out and was inconclusive; the successful controls used the existing working path. No system proxy settings were changed.

Installed-client correspondence

Read-only inspection found the same hydratePinnedThreads implementation in the renderer and native host-manager bundles. For hostId="durable", it unconditionally gives hydrateThreads requestOptions containing threadAccess="shared". The custom-section startup hydration query calls hydratePinnedThreads.

This matches the current Desktop log failures for the two exact affected targets:

2026-10-16T05:58:55.030Z, target B: thread/read, source=thread_hydration, priority=background, -32003 "thread access denied".
2026-10-16T06:00:44.723Z, target A: same method/source/error.

The prior generic description "automatic reads are denied" is therefore narrowed to a specific, reproducible access-mode difference. In these two cases, the ordinary owner read works and the forced shared read fails. This does not establish that every durable thread has the same ownership semantics.

Candidate correction and validation boundary

The hydration policy should distinguish owned tasks from genuinely shared tasks. One candidate is to try ordinary/owner hydration first, then use shared hydration only for still-unresolved targets, preserving existing archive and error behavior.

The two actual installed method bodies were evaluated in an isolated harness. The original forced-shared method reproduces omission of an owned child under the observed access behavior. An owner-first candidate passed 14 offline cases across the two copies, including fresh-state retries, mixed owner/shared targets, continued denial for inaccessible targets, local targets, and archived targets.

These are offline regression cases with the access outcomes mocked from the live controls. Genuine third-party shared threads were not accessed. They are not a claim that a patched desktop app or restart acceptance passed.

Deployment / requested fix

No installed client code, conversation database, credentials, cached thread contents, or security settings were changed. Normal write access to the installed app.asar is denied, and embedded ASAR integrity validation is enabled. A supported configuration switch for this hard-coded hydration choice was not found, so no local binary patch was applied and no security checks were disabled.

Please confirm whether the client should preserve owner access for aeon_child tasks rather than force shared access, or whether the backend shared-read behavior needs correction. Please identify a supported client/service fix. Acceptance is that the original task entries remain visible and openable after a normal Desktop restart without first opening them from Dot.

Related: #52733 and #54359. Existing private feedback: no-active-thread-01a140fe-81eb-7820-b096-d255fae2df24. The separate direct-Dot/local placement issue in #52331 is not asserted to share this cause.

Private target IDs, titles, account identifiers, credentials, project contents, local paths, and full logs are omitted.

Additional Windows evidence on Desktop 26.1013.31256, build 20586, MSIX 26.1013.3656.0 (production). The configured updater reports up_to_date.

Background thread/read failures persist with code -32003, message "thread access denied", source thread_hydration, and priority background. After a backed-up reset of only the cloud sidebar catalog cache and a full desktop restart, a subsequent five-minute sample still contained 120 failures across ten cloud chat identifiers. Maximum queue wait among those failures was 2 ms; no queue-expiration, integration-discovery-failure, or unavailable-renderer event appeared in that sample.

The supported read_thread(hostId="durable") tool successfully retrieved existing history from one exact chat that the background path rejects. This confirms accessibility through that path, not a raw WebSocket ordinary/shared A/B result on this profile.

Read-only inspection of this installed app confirms that hydratePinnedThreads in both the native and renderer bundles forces threadAccess="shared" for durable-host hydration. This corresponds to the existing access-mode investigation in this issue. No installed application code, signature, credential store, conversation database, original chat, or security setting was changed.

Available system RAM improved from roughly 0.5-1.4 GiB during earlier degraded checks to approximately 6.2 GiB after local recovery. The user now confirms that typing and scrolling are responsive after the cache refresh and restart. Background chat-access errors remain unresolved. These observations do not establish that access-denied retries caused every earlier freeze.

Please provide a supported recovery or identify the client/service fix that preserves owner access and makes denied hydration terminal until access changes. Acceptance should include original cloud chats loading after restart and background retries ceasing.

No private chat/account/request identifiers, titles, project contents, credentials, raw logs, screenshots, or personal paths are included. Submitted with the user's authorization.

Follow-up observation on a newer Windows Desktop build, 2026-10-17.

App version 26.1013.31256, build 20586; Windows package OpenAI.Codex_26.1013.3656.0. The configured updater reported up_to_date during diagnosis.
Six original durable conversations remain in the built-in list_threads, and correct-host read_thread(hostId="durable") retrieves original history. The user still sees only the two local conversations in the custom sidebar section after a full application restart. Same account and workspace were confirmed; switching to Codex did not restore visibility.

The new launch logs again record, for each of the six original targets:

method=thread/read
source=thread_hydration
priority=background
error.code=-32003
error.message="thread access denied"

Five missing conversations already have a persisted durable host mapping. A single incorrect host field therefore does not explain the whole observed failure. Earlier thread-ID navigation was accepted but followed by thread not loaded / no rollout found; navigation acceptance was not a successful page load.
Diagnostic side effect, tracked separately: a temporary section-move API failed with thread not loaded; rollback removed one original conversation's previous section association (8 members became 7), without deleting its history. A backed-up, narrowly scoped metadata correction verified immediately, then was overwritten by the running client. This intervention is not presented as the cause of the original six missing entries or as a recovery.

Please investigate the client access/host-context difference between successful built-in direct reads and denied UI hydration, and provide a supported recovery that preserves original conversation IDs, local-only history, and existing work. A clean-profile reproducer and exact backend root cause have not been established. We have not reset app data or recreated conversations.

Only versions, aggregate counts, sanitized error fields, and observed behavior are included. No account/email identifiers, private thread/request IDs, conversation titles or contents, local paths, raw logs, screenshots, credentials, or preference backups are attached.

Prepared and submitted by Codex on behalf of the user, with their explicit authorization.

Windows build 20770: same-connection ordinary/shared/ordinary comparison across 23 threads

Additional read-only confirmation on 2026-10-18, matching the access-mode contrast already reported here. Related background-retry reports: #51572 and #53677.

Environment: Windows Desktop 26.1013.40934, build 20770; MSIX package version 26.1013.4894.0.

Observed behavior: Desktop repeatedly issues thread/read requests with source=thread_hydration, priority=background, and -32003 / thread access denied. Supported ordinary reads of the same affected set succeed for 18 targets; five retained internal dreaming references return not found.

Controlled online comparison

Two fresh diagnostic WebSocket connections performed 69 metadata-only reads across all 23 targets. For every target, all three steps used the same connection, signed-in context, target ID, and includeTurns:false:

Ordinary thread/read, without params.threadAccess.
The same read with params.threadAccess:"shared".
The ordinary read again, with that parameter removed.

Only the access parameter changed between the three read configurations; request IDs were unique. Normal TLS certificate validation remained enabled. These were direct WebSocket comparisons, avoiding the Desktop HTTP-interception path as a confounding variable.

Target group	Count	Ordinary before	Shared	Ordinary after
Otherwise-readable targets	18	Success; returned ID matches	`-32003: thread access denied`	Success; returned ID matches
Retained internal dreaming references	5	`-32600: thread not found`	`-32003: thread access denied`	`-32600: thread not found`

Every target completed exactly three reads. This establishes that the shared parameter triggers the denial for the 18 otherwise-readable targets on this installation. It does not reveal the backend's internal authorization rule, prove that the five unavailable references were deleted, or establish the access semantics of genuinely shared third-party threads.

Installed-client correspondence

Read-only inspection of this build confirms that durable-host hydratePinnedThreads explicitly supplies threadAccess:"shared". The catalog merges retained references into its candidates, and its error/retry handling can reissue denied batches.

A separate concrete call-signature mismatch was also verified offline: the catalog calls hydratePinnedThreads(ids, {throwOnReadError:true}), while the installed signature is (ids, onArchived, {throwOnReadError=false}={}). The intended option therefore enters the callback position and leaves the third-argument option at its default. This is an additional client-side defect; it does not itself explain the server's authorization decision.

Requested supported fix

Please verify per-target ordinary/shared access selection instead of forcing shared for every durable catalog entry, correct the call signature, and classify not-found/access-denied failures separately with bounded retries. Preserve original conversations and access controls. Please identify the client/service version containing a supported fix or recovery procedure.

Intervention and privacy boundary: No model turn, task message, file-operation RPC, or conversation mutation was started. No installed application code, authentication store, conversation database, cached state, permissions, proxy configuration, or certificate-validation setting was modified. No local application repair is claimed.

This comment contains only versions, aggregate counts, sanitized error fields, and test conclusions. Private conversation/request/account/user identifiers, titles, contents, project names, local paths, credentials, screenshots, raw logs, and diagnostic attachments are omitted. Prepared and submitted by Codex with the user's explicit authorization.

Additional Windows observation on October 18, 2026, after the official Microsoft Store update.

Environment

Desktop app 26.1013.40934, build 20770, production channel.
Microsoft Store package 26.1013.4894.0.
The configured update check reports up_to_date.

Observed behavior

The app repeatedly returns -32003, thread access denied while hydrating four existing dot conversations: one root and three subagent conversations. The supported read_thread(hostId="durable") tool successfully retrieves all four and returns normal response structures. This confirms access through that tool, while app loading remains unresolved.

Errors occurred at 2026-10-18T04:38:22Z and again around 05:02:10Z. The latter read-only check counted 37 access-denied error records per conversation in the current app session. Signing out and back into the same account, repeated restarts, and the official Store update did not resolve the errors.

This shares the error signature and app-versus-direct-read contrast described in this issue. A common root cause has not been established; no raw WebSocket access-mode experiment was performed on this account.

Submitted diagnostics

Feedback ID: 01a0ed85-1680-7691-aac1-5997b2ecbff1

The local upload record confirms successful feedback upload at 2026-10-18T05:01:22Z, with 15 attachments and attachments_failed=false. The desktop RPC also completed with errorCode=null. This is a feedback correlation identifier, not a support case number.

Please investigate the difference between app hydration and supported durable reads, and identify a supported client/service correction that restores access while preserving the original conversations and their history.

Additional user report from Windows desktop: an existing task created through Dot has been identified, but opening it repeatedly fails with a permission or wrong-account message. This is a paraphrase of the user-visible error; the exact error text and current app build have not yet been independently captured. The user reports being signed into their sole intended account and says repeated attempts have not restored access.

We found this issue while checking for an existing fix. We have not established that this installation shares the access-mode cause described in other comments, and we have not verified recovery of the affected task.

Please provide a supported recovery path that preserves the original task and conversation history, and identify the release or service change containing a fix when available. Please also specify any minimal additional diagnostics needed, preferably through a private support channel rather than requiring public task or account identifiers.

Additional Windows desktop report — October 19, 2026

The main Dot conversation repeatedly shows “Reconnecting…” and, today, recurring “Couldn’t refresh messages” errors. This also happens while remaining in that conversation, not only when returning from another chat. The conversation has been used for several weeks.

The user tested the same Dot conversation in the web browser and reports that it works normally there. The observed problem is isolated to the Windows desktop app.

Environment:

Desktop app 26.1013.40934, build 20770, production channel.
Microsoft Store package 26.1013.4894.0.
The configured app update check reported up_to_date.

Read-only inspection of the October 19 desktop session found:

24 live-update reconnect-scheduled events in the primary window, including 20 while the window was focused.
13 durable app-server WebSocket abnormal closures (code 1006, unknown reason) between 15:11:58 and 15:16:52 UTC, followed by reconnection attempts.
More than 31,000 background thread/read failures with -32003, “thread access denied”, in the inspected session beginning at approximately 12:36 UTC. A subsequent check attributed these repeated failures to thread_hydration across 100 targets.
Hundreds of app-server request-queue-full errors in the inspected session.

Sanitized example:
app_server_connection.closed code=1006 failureReason=unknown hasReason=false hostKind=durable reason="" transport=websocket

These are observations, not an established root cause. The background hydration failures may be separate from the main Dot messaging refresh failure; the exact failed message-refresh request was not captured. WebSocket code 1006 does not identify whether the failure originates in the client, network, or service. No context-length or message-size errors were found in the inspected logs, but conversation length has not been conclusively ruled out.

Please investigate persistent desktop-only Dot reconnecting and message refresh failures, and whether the background hydration/error volume contributes. If this belongs to a separate issue from the cloud-history/access problem tracked here, please triage accordingly. A supported fix should preserve the existing conversation and history.

No raw logs, private conversation content, account or thread identifiers, local paths, credentials, or attachments are included. Prepared with Codex assistance at the affected user's explicit request. No restart, sign-out, reinstall, or cache-clearing recovery is claimed for this occurrence.

Navigation Menu

Repository navigation

[Windows Desktop] Dot-created cloud history remains missing/access-denied after connection recovery; direct reads retrieve original messages #52129

Codex App version

Problem

Observed sequence

Selected diagnostic timing

Expected behavior / requested investigation

Investigation lead, not a confirmed root cause

Diagnostic interventions and limits

Related reports

Symptom and environment

Controlled live result: ordinary -> shared -> ordinary

Installed-client correspondence

Candidate correction and validation boundary

Deployment / requested fix

Windows build 20770: same-connection ordinary/shared/ordinary comparison across 23 threads

Controlled online comparison

Installed-client correspondence

Requested supported fix

Environment

Observed behavior

Submitted diagnostics

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows Desktop] Dot-created cloud history remains missing/access-denied after connection recovery; direct reads retrieve original messages #52129

Description

Codex App version

Problem

Observed sequence

Selected diagnostic timing

Expected behavior / requested investigation

Investigation lead, not a confirmed root cause

Diagnostic interventions and limits

Related reports

Activity

github-actions commented on Oct 8, 2026

Nver-theless commented on Oct 9, 2026

mrwillystudio commented on Oct 13, 2026

qqzyy commented on Oct 16, 2026

Symptom and environment

Controlled live result: ordinary -> shared -> ordinary

Installed-client correspondence

Candidate correction and validation boundary

Deployment / requested fix

thenorthen commented on Oct 16, 2026

yinkaizhu-dot commented on Oct 17, 2026

zwz7107 commented on Oct 17, 2026

Windows build 20770: same-connection ordinary/shared/ordinary comparison across 23 threads

Controlled online comparison

Installed-client correspondence

Requested supported fix

yooving-hue commented on Oct 18, 2026

Environment

Observed behavior

Submitted diagnostics

Oblivionjake commented on Oct 18, 2026

AnvilwakeStudios commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions