[Windows Desktop] Background hydration repeatedly reads access-denied conversations after restart

Summary

After restarting Codex Desktop on Windows, a bounded log window recorded 742 distinct background thread/read requests across 157 conversations, ending in access-denied responses. The requests came from two Desktop renderers and continued through the product's thread_hydration path.

Please investigate the request repetition, terminal-error handling and cross-renderer coordination while preserving the existing authorization boundary. This report does not ask the app to bypass access denial.

Environment

Observation date: October 7, 2026; all times below are UTC.
Windows desktop package: 26.1002.6548.0.
Desktop app-server: 0.162.0-alpha.2.
Separately installed CLI: 0.160.1.
Exact Windows OS build is not included in this report.

The app and runtime version fields are reported separately. The observation followed an app update, but no controlled before/after comparison establishes the update as the cause.

Observed sequence

Around 03:46 UTC, I encountered an app-server queue-full error and could not resume a chat.
I manually restarted the desktop app at 03:50:37 UTC.
Between 03:50:52.036 and 03:52:14.362 UTC, the installed app recorded the following background read activity:
- 742 distinct thread/read request IDs
- 157 distinct target conversations
- Renderer A: 585 requests
- Renderer B: 157 requests
- source: thread_hydration
- priority: background
- error code: -32003, classified in the diagnostics as thread access denied
- failureReason: null
- observed queue waits: 0–1 ms

Renderer A/B are aliases, not published process or window identifiers. A method-specific recount found 742 unique request IDs and zero duplicate error rows. These are not counts of user clicks, model turns, or unique conversations.

Two post-restart thread/resume response_routed entries show errorCode=null and no matching failure events: 03:51:03.018 UTC (578 ms) and 03:51:57.161 UTC (1,094 ms), both queueWaitMs=0. Result payloads were not logged; complete UI chat reopening remains unproven.

Read-only client inspection

The inspected installed client contains a metadata query configured with retry: 1 and a path that hydrates pinned entries in parallel. These are candidate contributors to examine, not a complete causal explanation for the 742 requests. The capture does not establish which request came from which query lifecycle, that all 157 conversations were pinned, or that this single retry setting explains the full repetition.

The measured calls are attributed by Desktop telemetry to its product hydration path. They were not generated by an agent-run polling/stress test or a custom wrapper.

What the evidence establishes

High-volume repeated background reads of a bounded set of conversations after desktop restart.
Access-denied responses, rather than queue-expiry responses, in the measured post-restart window.
Two renderers contributing requests during the same window.
A read-only source-inspection lead involving retry and parallel pinned-entry hydration.

Important limits

The 0–1 ms queue waits do not establish queue saturation during this post-restart window.
The earlier owner-visible queue-full/resume failure and the later read burst are temporally adjacent; no causal connection has been proven.
The current queue depth and pre-restart occupied-request inventory are unknown.
The report does not establish why these conversations were denied, whether their denial was correct, an actor/account mismatch, deletion, corrupted history, or a common cause with separately observed missing native tools.
Request volume is not a measurement of billed usage, financial loss, CPU saturation or duplicate task execution.
This is a retained observation and installed-client inspection, not a deterministic clean-install reproduction.

Expected behavior / requested investigation

Please make background hydration bounded and coordinated across renderers:

Correlate retry, invalidation and hydration ownership for each target and determine why the same denied reads are reissued.
Distinguish terminal authorization denial from transient transport failure, and avoid repeatedly retrying a denied target without a relevant authorization/state change or explicit user request.
Coalesce duplicate in-flight reads and bound background concurrency while preserving capacity for the selected conversation.
Preserve thread entries and history with a clear inaccessible state. Do not silently delete, unpin, reassign ownership or relax permissions.
Expose useful typed denial/route diagnostics instead of failureReason=null where possible.
Verify with harmless fixtures covering multiple renderers, pinned entries, permission changes, reconnect/restart and denied targets. Preserve tests that prevent unauthorized reads.

Please identify any supported recovery for the existing affected conversations and the applicable app/service version. Clearing history, rewriting account/actor identifiers or weakening review is outside the requested repair.

Related reports and duplicate review

#36914: background collaboration/thread hydration starves interactive requests. Its captured requests waited until queue expiry; this report's measured reads have queue waits of 0–1 ms and access-denied responses.
#50561 comment 5973041135: a specific -32003 read failure explicitly identified placement belonging to a different actor. No equivalent actor diagnostic has been established here.
#50812: sent-read timeouts retain host RPC slots. The earlier queue-full symptom may be related, but this report does not reproduce that mechanism.
#51087: repeated archived-thread resume failures on macOS. The terminal-state retry concern is adjacent, but the platform, method, error and observed outcome differ.
#42589: Windows VS Code multi-window hydration/resume conflicts. This report concerns Desktop read denials, not active-writer conflicts.

I searched open and closed issues for thread_hydration, thread/read with -32003, thread access denied, hydration retries and pinned hydration. No exact report of this repeated access-denied Desktop read signature was found. Please consolidate if an existing issue preserves these distinctions.

Privacy

This report contains only sanitized timings, versions, aggregate counts and selected diagnostic fields. No private paths, conversation/request/process identifiers, account or actor identities, conversation content, application architecture, credentials, screenshots or raw logs are attached. No new reproduction or denied-action workaround was run to prepare it.

Still happening on October 8, 2026, with Windows desktop package 26.1002.7124.0. The interface is slow, and waiting for replies is also slow.

Today's captured desktop log contains 1,088 failed background thread/read requests targeting the same eight conversation IDs between 10:35:53.991 and 11:13:32.833 UTC. These requests report:

source=thread_hydration
priority=background
error.code=-32003
error.message="thread access denied"
failureReason=null
queueWaitMs=0 or 1

The measured read durations had a median of 105 ms, a 95th percentile of 192 ms, and a maximum of 6,981 ms. Those queue waits do not establish queue saturation.

Read-only local inspection found no matching rows for those eight IDs in the local thread database, while references remained in persisted dot/output state, including primary-aeon-selection-v1 and orbit-outputs-v1. This is a concrete reconciliation lead. It does not establish permanent deletion, that these conversations should exist locally, or that access denial is incorrect.

The requests came from the desktop's background hydration path, not a custom polling or stress test. The UI lag was reported during the same session; its causal relationship to the retry loop has not been isolated.

Please investigate why these cached references repeatedly trigger reads after terminal denial, and provide a supported recovery that preserves conversation history. Repeated access-denied targets should have bounded retries and an actionable unavailable state.

Separately, the preceding six-hour backend capture contained 112 response-stream retry warnings and 19 HTTP fallback messages. Some retry sequences spanned over two minutes. Both Windows socket error 10053 and server-closed WebSocket messages appeared. A shared cause with the hydration problem has not been established.

Basic network checks were healthy during diagnosis: eight gateway pings and eight public-endpoint pings had no loss, and ordinary HTTPS probes completed in under one second. Free memory was about 16 GB, overall CPU use was about 18%, and the sampled disk queue was zero. These are bounded observations, not proof against intermittent network or rendering faults.

Only aggregate measurements and selected error fields are included here. No private conversation IDs, account details, local paths, conversation content, credentials, screenshots, or raw logs are attached.

Additional same-installation evidence for issue #51572, observed on October 9, 2026 (UTC+8).

Environment: Windows package OpenAI.Codex 26.1002.7124.0; desktop version 26.1002.52244, build 13536. The built-in updater reported up_to_date.

Desktop repeatedly logs background thread/read failures with error -32003: thread access denied, source thread_hydration. One 30-second sample contained 40 failure events across the affected group of 10 cloud conversations.

For one affected, completed cloud conversation, an explicit built-in read_thread call with hostId="durable" successfully returned the original user and assistant messages. In the same application instance, background reads of that exact conversation subsequently failed four more times over approximately 13 seconds. Thus, the history remains retrievable through one supported path while automatic Desktop hydration fails. This does not establish the authorization context or transport used on the failing wire request.

Read-only inspection of the installed client found that durable pinned-thread hydration explicitly requests shared access, whereas the general background hydration entry point does not supply that option. This is an investigation lead, not a confirmed complete explanation. A temporary supported sidebar-pinning attempt did not restore loading; the original sidebar membership was restored.

Please investigate the difference between explicit durable reads and automatic hydration, and provide a supported mitigation that stops repeated authorization failures without deleting history, changing ownership, or weakening access controls. Persistent denials should not trigger repeated background reads without a relevant state change or explicit retry.

No conversation contents or identifiers, account details, local paths, credentials, screenshots, or raw logs are included here. The separate hidden-window reminder loop was resolved locally by pausing its stale automation and should not be conflated with this remaining failure.

Windows follow-up: default reads succeed for 21 of 25 targets while automatic shared hydration is denied

Additional navigation experiment at 11:00–11:08 UTC+08:00

There is a second, distinguishable failure in the default navigation path. For one default-readable cloud target, the supported navigate_to_codex_page(threadId) tool navigated without a durable host parameter. Runtime logs then showed maybe_resume_started hostId=local and local thread/resume failed with no rollout found.

The installed URI handler explicitly supports codex://threads/<thread-id>?hostId=durable, with optional threadAccess omitted. Using that handler for the same idle target produced maybe_resume_success and thread_hydration outcome=success. A second independent idle cloud target also completed both stages through the host-qualified URI. No message was sent and no business turn was started.

The measured hydration durations were 10.318 s and 7.296 s, including 1.791 s and 5.879 s of background time. They establish completed restoration, not satisfactory latency or a controlled foreground benchmark. The /local/ route prefix is used even for durable routes, so host classification must use the hostId query and runtime metadata rather than the prefix.

Automatic background shared hydration continued to return access denied. In one bounded minute (11:00:00–11:00:59), 25 unique targets generated 100 denied requests. Do not interpret that sample as a permanent fixed request rate. The host-qualified route is a usable workaround for the two validated targets, not a fix for the background query or proof that all 21 default-readable targets reopen successfully.

Please fix host discovery/propagation in ordinary navigation separately from access-mode selection in background hydration. A missing local rollout for a cloud target must not lead to creating a local copy or changing task ownership. The four targets that fail ordinary reads still need separate service-side investigation.

Observed on October 13, 2026, Asia/Shanghai:

Desktop displayed version: 26.1007.21434, build 13901, production channel.
Windows Store package: 26.1007.2314.0.
Desktop app-server: 0.162.0-alpha.17.2. This is distinct from the separately installed CLI.
The built-in update check returned up_to_date. The public Windows production release feed also advertises package 26.1007.2314.0.

Same-target comparison

The normal Desktop background path repeatedly returns -32003 / thread access denied, with method=thread/read, source=thread_hydration, and priority=background, for the same 25 cloud-associated targets.

After a fresh application launch, a bounded audit used the supported read_thread tool with hostId="durable", turnLimit=1, and includeOutputs=false against those 25 IDs. Results: 21 successful history reads, 4 failures. Background hydration continued to deny all 25. These are read checks, not 25 successful UI reopenings or unit tests.

The four failed default reads were checked once more without an explicit host to test the host-selection hypothesis; all four still failed. Their existence/accessibility could not be determined. Please do not interpret this as deletion or assume that an access-mode fix alone restores them.

Installed implementation evidence

Read-only inspection found this concrete call chain:

cloud-aeon-sidebar-threads collects Orbit attachments and retained sidebar thread references.
It calls the manager's hydratePinnedThreads(ids, {throwOnReadError:true}) wrapper.
The wrapper inserts the archive callback as argument 2 and forwards options as argument 3 to the thread store. Thus, the option is actually propagated; there is no two-argument/three-argument mismatch.
The store sets requestOptions.threadAccess="shared" whenever hostId==="durable", with no per-target distinction between a default-readable target and an explicitly shared target.
The supported read_thread handler's ordinary metadata lookup does not explicitly supply that shared marker. This corrects an earlier hypothesis that the successful tool path was itself explicitly shared.
The sidebar query propagates a read error and also checks for incomplete metadata. Focus, reconnect, and its error refresh interval can repeat the query.

The function name does not establish that all 25 targets are user-pinned. Final wire parameters and server-side authorization decisions were not captured, so the transport/authorization explanation remains an engineering lead supported by the same-target comparison, not a complete server-side diagnosis.

Shared-link experiment and recovery

A single supported app link with explicit shared access was tried for one known default-readable target. Its critical read/history/resume attempts were denied, and subsequent ordinary reads of that target failed in the same application instance. An unchanged control target remained readable. The experiment was not expanded to other targets.

A later full application relaunch cleared that side effect: the first target's default read succeeded again. The original automatic hydration failures remained. No account permissions, credentials, database rows, installed files, or cloud history were changed to perform or recover from this experiment.

Requested engineering outcome

Please compare the default and explicit shared paths for the same target, including access propagation, transport selection, and the backend's authorization decision. Please provide a signed Windows build or supported recovery procedure that:

Selects the appropriate access mode per target and preserves intentional shared access.
Does not remember an unsuccessful shared attempt as a successful access mode.
Keeps readable entries usable when another entry cannot be read, with a visible per-entry failure state.
Bounds authorization-denial retries until a relevant state change or explicit retry, while retaining normal handling of transient transport failures.
Preserves history, archive state, project associations, and account authorization boundaries.

Any automatic fallback between modes must be bounded and must not be triggered by timeouts, cancellation, or rate limiting. Please investigate the four targets failing both supported host-selection variants separately.

The installed Windows binary enforces embedded ASAR integrity, so an independently modified local bundle cannot provide an authentic Desktop repair validation while retaining the current signed integrity chain. No client patch was installed and no integrity checks were disabled.

Related: #51572 and #51675. Both remained open when checked; no fixed Windows build was identified. This comment was prepared with AI assistance and is shared with the user's explicit approval.

Follow-up for openai/codex issue #51572 — Windows Desktop build 13901

Observed on 2026-10-13, Windows x64.
Desktop version: 26.1007.21434, build 13901, production channel.
Windows package version: 26.1007.2314.0.
Bundled local app-server: 0.162.0-alpha.17.2.
The built-in updater reported up_to_date earlier that day.

The same access-denied hydration behavior persists in this newer installation:

After a full application restart, 1,588 access-denied error rows targeted 27 conversations between 02:31:31 and 02:55:54 UTC. These are log-row counts, not model turns or billed requests.
Failing fields: method=thread/read, source=thread_hydration, priority=background, code=-32003, message="thread access denied".
A later recount at 03:16:15 UTC found 1,982 matching rows with 1,982 distinct request IDs across 28 targets in the same app run, including 52 failures in the preceding five minutes. Three log files were read with writer sharing enabled, with zero read errors. The later observation includes ordinary ongoing app activity, so it is not a controlled before/after benchmark.
Supported explicit read_thread(hostId="durable") succeeded for three of the same targets. One target was rechecked later and still returned its original history.
Reopening one affected conversation through the thread-ID-only navigation tool selected the local host and returned -32600/no rollout found. The original view was restored, and the subsequent background reads for that target still returned -32003. This did not repair the issue and is not evidence of lost history.

Read-only installed-client findings:

The sidebar preview hydration calls hydrateBackgroundThreads with includeTurns=true and maxTurns=5. Failed loading can remove a target from the local attempted set, allowing it to be scheduled again as reactive state changes.
readHydrationThread first calls readThread(includeTurns=false). General background loading may have no explicit shared-access context for an unloaded conversation; pinned durable hydration explicitly supplies it.
readThread caches normalized thread_not_found errors, but does not cache thread access denied as a terminal background failure.
The durable transport intercepts eligible thread/read messages with a strict params schema and sends HTTP GET /v1/threads/{id}. params.threadAccess is absent from that strict schema, while the top-level message schema does not declare threadAccess. This is a routing/authorization-context investigation lead, not a captured wire trace or a proven server-side cause.

A standalone, offline guard proposal was tested against the unchanged installed readThread method using synthetic responses. All 12 checks passed. The installed function made 3 requests for 3 persistent denials; the guard reduced 100 attempts to one denied outbound call. Tests also covered concurrent coalescing, foreground retry, transient failures, target/access-mode separation, account/workspace/host context change, explicit reset, bounded cache size, unchanged successful responses, and an old in-flight failure arriving after context change.

The proposal preserves authorization errors and does not grant access. It is not applied to the installed application and does not establish a production fix. Product integration must bind the guard to real authorization-context lifetime and explicit refresh events.

Please provide a supported fix for the existing Windows installation:

Preserve the correct access context and transport selection between native direct reads and renderer hydration.
Stop automatic repeated authorization failures until an explicit retry or relevant authorization-context change, and coalesce duplicate reads.
Preserve chats, sidebar membership, permissions and active work.
Include a regression case for top-level versus params shared-access propagation through the HTTP interceptor.

Related: #51675, #52129, #53178.
No private thread IDs/titles, account identifiers, paths, message contents, credentials, raw logs or screenshots are included. No installed binaries, credentials, permissions or conversation databases were changed. Prepared with AI assistance and submitted with the user's explicit approval.

Follow-up for openai/codex issue #51572: a controlled archive/unarchive trial does not repair background hydration

Observed October 13, 2026, on Windows Desktop package 26.1007.2314.0 (displayed app version 26.1007.21434, build 13901). The same desktop main process remained running throughout the trial.

One idle cloud target with a completed last turn was used. The user authorized only temporary archiving of that target, followed by unarchiving and readback. No business message or model turn was started. A separate active target was observed without changing its state.

Explicit background thread_hydration failure counts, deduplicated by request ID:

UTC window	Trial target	Control target	Other targets
07:49:15–07:54:15, before archive	1	1	23
07:55:25–07:58:54, while archived	0	3	70
07:59:53–08:05:11.511, after restoration	1	1	23

The windows differ in duration and activity, so aggregate counts are not a latency benchmark. While archived, the trial target had no thread/read requests in the measured window; other targets continued receiving -32003 access-denied errors. After unarchiving, the trial target again received the same background denial.

The supported archive operation succeeded and the target appeared in the archive list. Unarchive RPC telemetry reported errorCode=null, but the tool's subsequent loading stage reported that the unarchived conversation could not be loaded. Rather than repeat the mutation, independent readbacks confirmed that the archive list returned to its original empty state, the target reappeared in the active list, and the supported default durable read succeeded. The latest turn ID, status, timestamps and bounded returned item data matched the pre-trial values. This is not a comparison of every historical message or proof of complete UI hydration. The server updatedAt changed as a normal mutation side effect.

Read-only client inspection shows that getUnarchivedThreadIds filters archived targets before durable hydratePinnedThreads explicitly requests shared access. An offline harness executing these two unchanged methods with dummy data passed 8 checks. The harness was not integrated into the installed client and is not a client repair.

The trial rules out temporary archive/unarchive as a lasting recovery for this target. Permanently archiving accessible conversations would hide affected entries; it would not correct access-mode selection or make terminal denial retries bounded. Please preserve active conversations and intentional shared access while fixing these paths, and provide a signed Windows build or supported recovery procedure. Please also distinguish successful unarchive RPC/state restoration from failure in the following client loading stage.

The target's archive flag was restored; no other conversation was archived. Worktree automatic cleanup remained disabled, and no cleanup operation was added for the target. Installed client files, signature/integrity settings, credentials and account permissions were unchanged. No private target IDs, titles, account IDs, paths, conversation contents, screenshots or raw logs are included in this follow-up.

Prepared with AI assistance and submitted with the user's explicit approval.

Additional Windows Desktop evidence from an independent installation on October 13, 2026.

Environment verified locally:

Desktop app version 26.1007.21434, build 13901, prod (installed package metadata; About dialog not inspected).
Windows package 26.1007.2314.0; bundled executable reports 0.162.0-alpha.17.2.
Microsoft Windows NT 10.0.22631.0 x64.
ChatGPT sign-in; subscription tier not independently verified.

Two bounded observations in the same application run:

UTC interval on 2026-10-13	Distinct denied request IDs	Distinct target threads	Maximum logged queue wait
12:18:30.466–12:23:30.466	176	11	1 ms
12:36:54.113–12:41:54.113	99	11	1 ms

These are ordinary background requests, deduplicated by request ID, not model turns or a custom polling test. The different counts are not a controlled performance comparison. Twelve distinct denied targets were observed across the inspected application run.

Failure fields:

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

Read-only inspection found references to affected targets in the durable cloud sidebar cache, dot subtask state and retained output state. This establishes retained references, not cache corruption, permanent deletion, or whether denial is correct.

The installed client's read path remembers normalized thread_not_found failures, but does not remember thread access denied in the same terminal-failure cache. The error-classification table also lacks that message. This agrees with the terminal-retry investigation already described here; it is a code-level lead, not a captured server-side authorization trace or a complete attribution of every retry trigger.

Please provide a supported recovery or signed client fix that bounds repeated denied background reads and coalesces duplicates, while preserving history and the existing authorization checks. Reconsider a denied entry after a relevant authorization-context change or explicit user retry. Do not silently delete entries or change access modes to suppress the errors.

No client patch, cache deletion, permission change or rejected-history read workaround was performed. The current sample does not establish queue saturation, billed usage, or a causal connection to separate browser problems. Private thread/request/account IDs, titles, paths, conversation contents, credentials and raw logs are omitted.

Prepared with AI assistance and submitted with the user's explicit authorization.

Independent Windows observation on 2026-10-14: repeated denied background reads

Additional evidence collected at the account owner's explicit request. This is an existing-profile observation, not a clean-install reproducer.

Environment verified locally:

Windows 11, build 26200.
Desktop 26.1007.21434, build 13901, prod; updater reports up_to_date.
MSIX 26.1007.2314.0; bundled CLI 0.162.0-alpha.17.2.

In retained desktop logs after the 01:20:46 UTC+08 boot, 1,830 error rows between 01:22:16.494 and 02:11:54.948 contain:

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

The rows refer to 18 distinct target conversations. Request IDs were not available in this error-row extraction, so 1,830 is a log-row count, not a verified count of unique requests, model turns, billable calls or user actions. The desktop files were read through approximately 02:16 UTC+08; the later absence of rows is not proof that retries permanently stopped.

The current local chat was not one of those 18 logged targets. A supported read_thread call successfully read that current local chat. No reads of the denied targets were attempted to bypass the denial; this control does not prove their histories are accessible or deleted. Ordinary shell, sandbox and benign Chrome-extension input/click/read controls passed. Current account sign-in and the locally configured network process were present, but this does not prove every remote authorization context is correct.

Please investigate bounded retry/terminal-denial handling and provide a supported recovery that preserves history and access controls. The observed pattern resembles this issue; a common root cause, cache corruption, identity mismatch, billing impact or causal link to UI slowness has not been proven. No app patch, cache purge, account change, conversation-database edit or permission relaxation was performed.

Only sanitized versions, generic error text, aggregate counts and timings are included. No private chat/request/account identifiers, local paths, credentials, screenshots, raw logs or business files are attached.

Windows follow-up: successful cloud history reads, continuing background denials, and a fresh runtime-resume failure

Observed on October 14, 2026, on an existing profile. Windows package OpenAI.Codex 26.1007.9446.0; built-in updater reported Desktop 26.1007.71326, build 20398, production. These are separate version fields. This is retained diagnostic evidence, not a clean-install reproducer.

Background access failures remain reproducible. A bounded 180-second log window ending at 10:10:57 UTC contained 72 distinct background access-denied request IDs across eight targets, with thread/read, source=thread_hydration, and -32003: thread access denied. Seven of the original eight target IDs matched retained dot/sidebar catalog entries; this does not establish that those entries are corrupt or should be deleted.

One affected cloud target remains readable but cannot resume. After one graceful application restart at approximately 10:28 UTC, a single host-qualified navigation to that existing target selected durable and produced an actual fresh runtime-resume request:

UTC on 2026-10-14	Result
10:30:08.204	Fresh `maybe_resume_started` on `durable`
10:30:08.862	Metadata `thread/read` succeeded
10:30:09.500-09.915	Items and turns reads succeeded
10:30:10.460-10.461	`thread/resume` failed with `-32600: thread not found`
10:30:11.115	Final hydration outcome was failure

A subsequent supported native read still returned completed history with 34 items. Background reads of the same target also received -32003 after its successful foreground reads. This establishes a mismatch between the readable saved records and the failing resume path; it does not prove deletion or identify whether runtime placement, access context, thread type, or client routing is responsible. The resume failure may require a separate issue; a common cause with the background denials is unproven.

The fresh test occurred after the separately reported Codex/ChatGPT Work service incident was marked resolved at 09:53 UTC. Ordinary model work recovered independently. Earlier same-process navigation attempts emitted no new thread/resume, so only the fresh post-restart attempt above is counted as runtime acceptance evidence. The restart worker wrote zero saved-state bytes, and the before/after saved-state hashes matched.

Read-only installed-client inspection found that dot catalog hydration explicitly selects shared access and refreshes on mount, focus, reconnect, and a conditional one-minute error interval. The examined not-found negative-cache handling does not include access-denied responses. These are investigation leads, not a wire trace or a confirmed authorization diagnosis. A known-host route restored one separate SSH-hosted chat, but the explicit cloud-host route did not restore this cloud runtime.

Please investigate both the repeated background denial handling and the same-target foreground-read/runtime-resume discrepancy, or identify the appropriate separate tracking issue. A supported recovery should preserve existing history and authorization checks, make accessible cloud chats resumable, and avoid repeatedly retrying denied background reads without a relevant state change. Please provide a fixed build or supported recovery procedure when available.

UI slowness was reported, but its causal relationship to these failures was not quantified. This report does not establish model billing, queue saturation, or a shared cause with the separate 429 incident. No cache purge, permission relaxation, ownership rewrite, application patch, synthetic model message, or replacement chat was used for this test. Private identifiers, titles, paths, account information, conversation contents, and raw logs are omitted.

Prepared with AI assistance and submitted at the account owner's explicit request.

恒久修正の依頼と追加観測（Windows、2026-10-17）

この報告と同型の背景読込みエラーを確認しました。会話や履歴を保持したまま、認可拒否後の反復取得を抑える恒久修正と、対応するアプリ版・安全な復旧手順の案内をお願いします。

確認した環境と結果

Windows パッケージ: OpenAI.Codex 26.1013.4894.0。アプリの再起動・更新後の観測です。
2026-10-17 18:59:25～19:00:25 JST（09:59:25～10:00:25 UTC） の約60秒間に、thread/read の -32003 / thread access denied を 200件記録しました。priority=background、source=thread_hydration です。
同じアプリ起動中の 18:57:34～19:03:53 JST の集計では、同じ 50対象に各20回、合計1,000件の拒否がありました。これらはエラー記録の件数であり、モデル実行数や課金数ではありません。
拒否対象の1件は、通常のサポートされた read_thread(hostId="durable") でメタデータを取得できました。本文・全履歴の取得成功や、2経路の認可文脈が同じことまでは確認していません。認可条件や認証情報は変更していません。
後の 19:32:08～19:33:08 JST（10:32:08～10:33:08 UTC） の約60秒間は、会話一覧取得を含む通常操作下で同種エラーが 0件でした。観測終了後の時刻までログが記録されていることを再読して確認しました。すでに調査前から反復が停止していたため、今回の操作で解消したとは主張しません。

体感上の応答遅延もありますが、この拒否反復との因果関係や、実際の回答速度改善は確認できていません。固定条件での再現手順や、サーバー側の認可判断も未確定です。

お願いしたい恒久修正

型付き認可拒否を一時的な通信障害と区別し、同じ認証・アカウント・ホスト・アクセス区分のまま、拒否された対象を背景で繰り返し取得しないようにしてください。
関連する認証・ワークスペース・権限等の状態変更、または利用者の明示的な再試行で再評価できるようにしてください。停止状態が別アカウントや別アクセス区分へ混ざらないことも必要です。
通常経路と共有経路の認可文脈・転送方式の整合性を調査してください。認可項目の除去や権限緩和を求めるものではありません。
一覧更新や複数ウィンドウからの同一対象への進行中リクエストをまとめ、選択中の会話の処理を優先してください。
会話・固定表示・所属・履歴を削除せず、読込み不能の状態と再試行操作を表示してください。

受入確認では、認可拒否・一時的通信失敗・権限変更・複数ウィンドウ・再接続・アプリ再起動を分けて検証し、無権限の共有会話が引き続き拒否されることを確認していただきたいです。これらは修正版に対する要求であり、こちらで実行済みのテストではありません。

関連する取得経路差の報告: #53178

アプリ本体、認証情報、アクセス権、会話データ、キャッシュは書き換えていません。このコメントには会話・リクエスト・アカウントの識別子、本文、ローカルパス、生ログ、認証情報を含めていません。

利用者の明示的な依頼に基づき、Codexが観測結果を整理して投稿しています。

Additional Windows desktop evidence — 18 October 2026

Related existing reports: #51572 and #52129

Installed Windows package: OpenAI.Codex 26.1013.4894.0. Owner reports slow launch, sluggishness and occasional crashes. A focused Windows Application log check found no matching crash/hang/WER record in the preceding two days. These observations do not establish crash causation.

Current-launch log sample on 17 October 2026: over 26,000 failed background thread/read calls, all error -32003, message thread access denied, source thread_hydration. Approximately 2,400 failures per hour; mean measured request duration 100 ms. Five preceding launches also contain the same pattern. Across all six launches, 28 target identifiers recur. Counts increase while the window is not focused/visible. Only aggregates are shared here.

Other repeated warnings include Conversation state not found and No promise for request ID. A precise out-of-memory scan found no match in the inspected current-launch logs. No newer installed-package upgrade was shown by the package manager on 18 October. This is not a complete Store UI update check.

Please identify the supported recovery and version fixing terminal access-denied hydration retries. Preserve original chat identifiers, history, settings, account/actor ownership and permissions. Do not require clearing history or bypassing access controls. The relation between these retries, startup time and reported crashes remains unproven.

Submitted by Codex, the AI assistant, at the owner’s explicit request. This report contains no raw logs, private identifiers, account details, chat contents, credentials or screenshots.

Navigation Menu

Repository navigation

[Windows Desktop] Background hydration repeatedly reads access-denied conversations after restart #51572

Summary

Environment

Observed sequence

Read-only client inspection

What the evidence establishes

Important limits

Expected behavior / requested investigation

Related reports and duplicate review

Privacy

Windows follow-up: default reads succeed for 21 of 25 targets while automatic shared hydration is denied

Additional navigation experiment at 11:00–11:08 UTC+08:00

Same-target comparison

Installed implementation evidence

Shared-link experiment and recovery

Requested engineering outcome

Independent Windows observation on 2026-10-14: repeated denied background reads

Windows follow-up: successful cloud history reads, continuing background denials, and a fresh runtime-resume failure

恒久修正の依頼と追加観測（Windows、2026-10-17）

確認した環境と結果

お願いしたい恒久修正

Additional Windows desktop evidence — 18 October 2026

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows Desktop] Background hydration repeatedly reads access-denied conversations after restart #51572

Description

Summary

Environment

Observed sequence

Read-only client inspection

What the evidence establishes

Important limits

Expected behavior / requested investigation

Related reports and duplicate review

Privacy

Activity

081522rsg commented on Oct 8, 2026

HeyDachui commented on Oct 8, 2026

fengni658 commented on Oct 13, 2026

Windows follow-up: default reads succeed for 21 of 25 targets while automatic shared hydration is denied

Additional navigation experiment at 11:00–11:08 UTC+08:00

Same-target comparison

Installed implementation evidence

Shared-link experiment and recovery

Requested engineering outcome

bhrhani commented on Oct 13, 2026

fengni658 commented on Oct 13, 2026

zshmtj commented on Oct 13, 2026

lvkangtao-ai commented on Oct 13, 2026

Independent Windows observation on 2026-10-14: repeated denied background reads

shogun301 commented on Oct 14, 2026

Windows follow-up: successful cloud history reads, continuing background denials, and a fresh runtime-resume failure

openthewaycwst-cyber commented on Oct 17, 2026

恒久修正の依頼と追加観測（Windows、2026-10-17）

確認した環境と結果

お願いしたい恒久修正

d0rjan commented on Oct 18, 2026

Additional Windows desktop evidence — 18 October 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions