Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   dotsIssues involving setting up ChatGPT dots or managing their ongoing work.Issues involving setting up ChatGPT dots or managing their ongoing work.

   on Oct 13, 2026
2. github-actions commented on Oct 13, 2026

   

   github-actionsbot

   on Oct 13, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [macOS Desktop] Persistent access-denied background hydration retries alongside high renderer CPU; restart does not resolve #53178
   • [Windows Desktop 26.1007.21434] Renderer exceeds 10 GiB and freezes; persistent retries of denied hydration #53277

   Powered by Codex Action
3. photosamurai commented on Oct 15, 2026

   

   photosamurai

   on Oct 15, 2026 – with ChatGPT Codex Connector

   Last edited by photosamurai

   More actions

   Additional evidence from macOS Desktop 26.1007.71326, build 20398, observed October 15, 2026. The configured updater reports up_to_date. Platform: Apple Silicon, macOS 27.0 (26A428).

   Same retry pattern in this build

   A bounded review of retained main-process logs from 2026-10-15 00:00:57.655 through 13:18:03.956 UTC found 9,357 distinct failed request IDs across 22 chat IDs. Counted entries have:

   method=thread/read
   source=thread_hydration
   priority=background
   error={"code":-32003,"message":"thread access denied"}
   

   Failures occur across three window IDs. All 19 thread records in the persisted cloud sidebar catalog are among the 22 denied IDs. This is an existing-profile observation, not a clean-install reproducer.

   Direct access succeeds, background access still fails

   Using the supported read_thread(hostId="durable") tool, two affected chats successfully returned their existing history. Corresponding thread/read responses had errorCode=null at 13:18:06.831 and 13:18:08.363 UTC, followed by successful turn/item reads.

   After those successful reads, each same chat produced four further denied background hydration requests, with the latest at 13:19:18.169 and 13:19:18.466 UTC. Direct reads therefore demonstrate access through that path but do not stop background retries. They do not establish which request parameter, transport, or server context differs.

   Current-build source confirmation

   Read-only inspection of the installed app-shared-8340f229c2b3.js confirms that the catalog mechanism described in this issue remains present in build 20398:

   • cloud-aeon-sidebar-threads merges cached thread references into the hydration candidates and calls hydratePinnedThreads(g,{throwOnReadError:!0}).
   • Its error wrapper (_4) copies an existing numeric status; it does not itself map JSON-RPC -32003 to a terminal HTTP-style authorization status.
   • The default retry predicate Bq allows up to three retries for errors without a numeric status. The catalog's refetchInterval returns one minute when the query is in error and Bq(0,error) permits retry; it also refetches on mount, focus, and reconnect.
   • The general read cache preserves normalized thread_not_found errors, while durable shared reads bypass the memoized read path. Access denial is not suppressed equivalently.
   • This identifies a concrete recurring-request path, not the only possible caller and not a demonstrated freeze mechanism. The custom-sidebar hydration query is a separate path with different error handling.

   Concurrent window-input freeze; causal link not established

   The user reports intermittent freezes requiring force quit in previous occurrences. During this occurrence, one window stopped accepting clicks and typing while the native macOS menu bar remained usable. A newly opened window works and was used for this investigation. This overlaps the symptom in #53707.

   Evidence limits:

   • Denied reads also occur in the working new window. Their presence alone is insufficient to explain a freeze.
   • The counted denied requests had median queue wait 0 ms, maximum 3 ms. No queue-full messages were found in the reviewed main-process files. This does not demonstrate a sustained backlog.
   • An initial renderer CPU observation was 94.6%; later measurements were near idle. Samples of both original renderers showed their main threads mostly waiting in native event handling. No persistent JavaScript loop was demonstrated, and the renderer PIDs were not conclusively mapped to the frozen visible window.
   • 238 ResizeObserver errors were recorded for the original window, latest at 13:03:32.618 UTC. They precede the reported freeze but do not establish its trigger.
   • Reload Window is present behind allowWindowReload in the shipped menu implementation, but the user confirms it is absent from View and Command+Control+R has no effect in this installation. It is not an available recovery here.

   Please investigate the authorization/access-context contrast and terminal-error retry handling described above, provide a supported mitigation that preserves original chats, and investigate window input/focus recovery separately unless a causal connection is demonstrated.

   No installed app files, signatures, credentials, access policies, chat databases, or original chats were modified. No raw logs, private chat/request/account IDs, titles, conversation contents, screenshots, or personal filesystem paths are included. Prepared and submitted by Codex with the user's authorization.
4. honghaoaa1230 commented on Oct 15, 2026

   

   honghaoaa1230

   on Oct 15, 2026 – with ChatGPT Codex Connector

   More actions

   Additional affected macOS profile on ChatGPT/Codex Desktop 26.1007.71326, build 20398 (bundle ID com.openai.codex), observed October 15–16, 2026, UTC+8. Platform: Apple Silicon, macOS 27.0.1 (26A434); Codex Framework 155.0.8059.40.

   Bounded measurements

   Across the retained main-process log segments for one app run, from 2026-10-15 03:49:02.526 to 16:10:52.495 UTC:

   • 10,898 failed log rows = 10,898 distinct request IDs, targeting 6 distinct cloud chat IDs.
   • Requests appear across 3 renderer/window IDs.
   • Each counted row has method=thread/read, source=thread_hydration, and error.code=-32003 / error.message="thread access denied".
   • These same six IDs account for all six thread records in the persisted cloud-aeon-sidebar-cache-v1 for host durable.
   • The cache's refreshStartedAtMs still corresponds to 2026-10-08 12:04:40 UTC+8, a week before this capture. Cached profiles associate the six records with the same active root thread.
   • The denied-read queue waits are at most 3 ms in this bounded capture. This does not establish queue saturation.

   Source confirmation / recovery concern

   Read-only inspection of this installed build's app-shared-8340f229c2b3.js confirms the issue's concrete retry path:

   1. The cloud catalog adds cached thread IDs back to its hydration candidates, including IDs absent from a newly fetched catalog.
   2. It calls hydratePinnedThreads(..., {throwOnReadError:true}).
   3. Its catalog error wrapper copies a numeric status if present. The logs show Orbit catalog task metadata could not be loaded ... status=undefined alongside these denials.
   4. The generic retry predicate accepts errors without numeric status for up to three retries; the catalog additionally schedules a one-minute refetch when that predicate allows it, plus mount/focus/reconnect refetches.
   5. The failed refresh does not reach the final reconciled-cache write, leaving old IDs eligible for later attempts.

   This corroborates the source path reported above; it is not a wire capture proving which caller accounts for every request. The backend reason for the access denial remains unknown.

   CPU observations and limits

   During short local measurements the main renderer ranged from approximately 10–24% CPU, with one earlier two-second sample at 85.8%, and approximately 2.1 GiB physical footprint. Percentages are per logical core. These observations do not quantify the retry loop's CPU contribution. A separately identified Safari WebKit process was also consuming significant CPU; all system load and fan activity must not be attributed to Codex.

   Please provide a supported way to stop this denied-background-read loop without deleting original chats, modifying app bundles or credentials, weakening authorization, or interrupting active local work/deployments. In particular, handle access-denied entries independently, stop retrying terminal denial until relevant access/identity changes or explicit retry, and allow stale catalog state to reconcile.

   No app bundle, credential store, chat database, access policy, original cloud chat, or running task was changed during this capture. This is an existing-profile observation, not a clean-install reproducer. No raw logs, screenshots, private chat/account/request IDs, chat titles/content, or personal filesystem paths are included.

   Prepared and submitted by Codex on the user's explicit request to report this bug to OpenAI.
5. ciwei0600 commented on Oct 16, 2026

   

   ciwei0600

   on Oct 16, 2026 – with ChatGPT Codex Connector

   More actions

   Additional evidence on macOS 26.5 (25F71), Desktop 26.1007.71326, build 20398. Observed October 16, 2026, UTC+8. The configured updater reports up_to_date.

   The repeated background denial remains reproducible in this existing profile. Eleven remaining cloud targets each produced 29 distinct failed requests in a bounded ten-minute baseline. A later two-minute check still contained failures for all eleven targets. Relevant fields are:

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

   A fresh supported read_thread(hostId="durable") successfully retrieved an existing turn and idle status for one of the same targets; background hydration for it continued to fail. Opening a durable deep link, both with and without an explicit shared parameter, did not restore UI loading. A previous app restart also did not resolve the loop.

   Read-only inspection of this installed build confirms the catalog path described in this issue: retained cached IDs re-enter hydration, hydratePinnedThreads is called with throwOnReadError:true, the error wrapper copies only an existing numeric status, and an unclassified denial remains eligible for three retries plus the catalog's one-minute periodic refresh. A failed refresh does not reach the final reconciled-cache write.

   An offline check evaluated the actual extracted readThread method, error classifier, and retry predicate against a fake transport, with no live app or network access:

   • Eleven synthetic IDs over five scheduling cycles: 55 transport requests for access denial, both with default access and explicit shared access.
   • Control using the normalized thread-not-found error with default access: 11 transport requests.
   • The actual generic retry predicate permits attempts 0–2 for an error without numeric status; a numeric 403 control is non-retryable.

   This isolates the retry-classification gap. It does not prove the backend cause of the first denial, identify the caller of every observed request, or quantify its contribution to overall slowness. Failing wire payloads and backend authorization decisions were not captured.

   Please provide a signed client/service fix or a supported live recovery that preserves existing chats and active work. In particular: reconcile owned/shared access correctly, classify explicit denial per entry, allow other catalog records to update, and coordinate denial suppression across windows without blocking explicit foreground retry or active turns.

   No installed app files, signatures, credentials, databases, caches, access policies, or original chats were modified in this follow-up. No active task was interrupted. This draft contains no private chat/request/account IDs, titles, project names, conversation contents, personal paths, screenshots, credentials, raw logs, or installed source excerpts.

   Prepared and submitted by Codex with the affected user's explicit authorization.
6. 0xdevalias commented on Oct 17, 2026

   

   0xdevalias

   on Oct 17, 2026

   More actions

   Independent build-20398 confirmation and clarification of retry cardinality.

   The actual Bq retry predicate returns true at failure counts 0,1,2 and false at 3 for {code:-32003,message:"thread access denied"}: initial attempt plus three retries = up to four attempts per failed query batch. A batch can read multiple threads; multiple renderers and minute-based catalog refreshes multiply totals. Numeric HTTP 403 is terminal, but this JSON-RPC error has no numeric HTTP status for the wrapper/predicate. This does not establish token expiry.

   Across the examined interval, 30 thread IDs were denied; 15 occurred in cached/pinned/order/reference state and six also existed in the local thread database unarchived. Local presence does not grant access on the durable service; cached local references can still be offered to remote hydration. The server's generic denial omits its specific authorization decision, so these observations do not distinguish obsolete host/reference/account scope or other backend policy reasons. It is not evidence of a macOS filesystem lock.

   The actual durable readThread method repeated five transport requests in five synthetic access-denied cycles, including explicit shared access; a normalized thread-not-found control made only one call because it was retained terminally. Live denials had median queue wait 0 ms, maximum 5 ms, median response about 49 ms: unnecessary recurring traffic, but not proof of continuously saturated queues or the initiating cause of a separate local send stall.

   A different UI banner, This is open in another app, uses AUs in app-initial-1ab6fbe93c4f.js, matching already has an active writer or already has a live local writer; the resume hook marks writer conflict. Please keep that single-writer conflict distinct from catalog read authorization and frontend owner/follower stream roles.

   Suggested fix: classify this access-denied code terminally for the affected host/account/thread/access scope, stop rehydrating it until meaningful identity/access change or explicit retry, reconcile stale references without deleting original conversations, and expose a sanitized denial reason. Do not change authorization scope merely to bypass the failure. Source and actual-code retry/read probes are included in #53197 (comment); the shared host scheduler problem is related load, not a proven common cause.

   Verified 2026-10-17: Codex Desktop macOS arm64 26.1007.71326, build 20398, macOS 26.6 (25G72). Installed archive Contents/Resources/app.asar SHA-256 2f231a64e6dd30111bcd09e03c149cd06c8679b25914842772423251c4608ded.

   Build-specific source provenance:

   • webview/assets/app-shared-8340f229c2b3.js: SHA-256 3b4cabc382e71f0da7398393a619d7c62d13dfae598a5fe2e9880ab8d31d1bf5.
   • .vite/build/main-CwxgTOle.js: SHA-256 87d52265eb13608a380fabcac47ecf13a39b981115c0960c18af563ea6d32d51.
   • .vite/build/src-DCNiwad_.js: SHA-256 86fb2066bbc2f7428864b76b46ef570b09eb1e92e81e9d6f089f5b048a66df25.

   Source observations below are version-specific. Offline probes evaluate extracted shipped methods in a Node VM with synthetic dependencies; they do not establish an unlogged live race. No app patch/restart, queue edit, direct send, or SQLite mutation was performed. Private text, annotations, account identifiers, task IDs, and raw logs are excluded.
7. dandelionxuan123-netizen commented on Oct 17, 2026

   

   dandelionxuan123-netizen

   on Oct 17, 2026 – with ChatGPT Codex Connector

   More actions

   Windows 当前版本仍反复读取访问被拒的聊天；同一台机器此前已累计三万多次

   这是本问题在 Windows 当前客户端上的补充证据。用户报告该问题已持续数日；当前新启动窗口中的数百次失败不能代表此前长期运行时的严重程度。

   当前环境与观察

   • Windows 桌面安装包：OpenAI.Codex 26.1013.4894.0。
   • 实际官方 CLI/core 报告：0.163.0-alpha.10.2；桌面与 CLI 版本分别记录。
   • 同一次桌面启动，从 2026-10-17 20:47:13 到 21:08:41（UTC+08:00）的有界观察已记录 764 个不同的失败请求 ID，涉及同一批 191 个云聊天。
   • 失败签名：method=thread/read、priority=background、source=thread_hydration、code=-32003、message="thread access denied"。
   • 前三个批次中，原窗口读取 191 次；用户确认新开窗口后，原窗口又读取 191 次，新窗口再读取 191 次。后来又出现一批 191 次拒绝。
   • 没有发送模型任务或重放失败请求来触发验证。不能把所有重复直接归因为无操作定时器。
   • 用户没有报告这台机器界面卡顿；本报告只处理后台重复读取及额外网络请求。未测量流量字节，未声称队列饱和或这些请求解释所有流量。

   同一台机器的历史严重程度

   本次重新读回同一台 Windows 机器保存的历史诊断回执，确认以下记录。时间统一为 UTC+08:00：

   观察时间或窗口	失败事件数	不同聊天数	计数范围
   2026-10-14 16:35:55 快照	25,806	179	旧桌面会话的累计完整拒绝事件
   2026-10-14 16:40:46 快照	27,076	179	同一累计计数的后续快照
   2026-10-14 16:58:07 快照	32,625	179	同一累计计数继续增长；不是额外新增 32,625 次
   2026-10-17 08:00:00–11:49:24	10,368	190	今日较早的另一个桌面会话日志窗口
   2026-10-17 20:47:13–21:08:41	764	191	当前版本的新启动会话，已确认 764 个不同请求 ID

   旧回执的计数定义仅包含完整 Request failed、method=thread/read、source=thread_hydration、code=-32003、message=thread access denied；没有把 response_routed 再计一次。10 月 14 日的旧计数未在本轮重新逐请求 ID 去重，因此按历史完整拒绝事件报告，不冒称已重做全量独立去重。10 月 17 日较早窗口另有两次 app-server unavailable，它们不包含在 10,368 次访问拒绝中。

   这些快照和不同会话窗口不相加成一个总数；聊天集合可能跨会话重叠。记录支持“至少在 10 月 14 日与 17 日均存在，单个旧会话曾累计三万多次”，不证明中间每一分钟持续请求，也没有流量字节测量。旧会话的精确运行包版本未随本表重新核定，不能把当前版本追溯套用于全部历史记录。

   当前版本的本机对应证据

   只读核查当前安装包，发现：

   1. cloud-aeon-sidebar-threads 查询调用 hydratePinnedThreads，并在读取错误时让整个批次失败。
   2. durable 主机的该 hydration 路径显式提供 shared 访问模式。失败请求本身没有记录这个 wire 字段，故不把静态实现当作每条请求的抓包证明。
   3. 目录错误包装器只复制已有的 numeric status。本次四次目录刷新错误的实际日志均为 status=undefined，时间与失败批次末尾紧邻。
   4. 实际重试函数 dv 在失败计数小于 3 时接受无 numeric status 的错误；catalog 还有错误状态下一分钟刷新，以及 mount/focus/reconnect 刷新。
   5. 最终缓存提交在 hydration 成功以后；批次失败无法完成正常的 catalog reconciliation。

   之前修复的短名称仍保持，原正文未变；多条被拒记录原本也有短名称。补名称没有消除这个访问拒绝与重复读取问题。

   请求的修复或正式恢复办法

   请提供适用于 Windows 当前签名客户端或服务端的修复：

   • 正确区分 owner/shared 读取语义，保留服务端授权边界；不要通过跳过拒绝或扩大权限获取结果。
   • 对明确访问拒绝按 account/host/thread/access 范围保存不可自动重试状态，逐条处理，不让一个拒绝反复重载整批。
   • 跨窗口协调与去重；在相关身份/权限变化或明确前台重试后才使该状态失效。
   • 允许正常条目完成目录同步，并给出不删除原聊天、不打客户端补丁的受支持恢复步骤。

   当前仍未知：服务端首次拒绝的具体授权规则；每条失败请求的完整 wire 参数；每次刷新具体由哪个调度事件触发。

   隐私与操作边界

   本次补充经用户明确同意，只发送脱敏文字。未包含私人聊天/请求/账号 ID、用户名、项目名、本机路径、正文、凭据、原始日志或截图。未修改客户端、数据库、缓存或安全策略；未删除或归档聊天。用户对新开窗口的时间确认与实际日志核对过。这里的隐私范围不包括任何另行由反馈界面自动附带的诊断内容。
8. jrsarnold commented on Oct 17, 2026

   

   jrsarnold

   on Oct 17, 2026 – with ChatGPT Codex Connector

   More actions

   Windows follow-up: the cloud-history retry problem remains after a targeted cache refresh and an alternate-network test on October 17, 2026.

   Environment: Windows 11 Pro 10.0.26300; desktop app 26.1013.31256, build 20586; MSIX 26.1013.3656.0; bundled CLI 0.163.0-alpha.10.2. The configured updater reported up_to_date earlier in this investigation.

   These are bounded observations of an existing profile, not a clean-install reproducer:

   Observation, UTC	Denied background reads	Distinct cloud chats	Queue-full errors
   Before cache refresh, 15:53:31–15:58:31	950	Not counted in this baseline	0
   After restart, 16:00:17–16:05:17	1,144	88	0
   Phone hotspot, 16:20:51–16:25:51	348	87	0

   The counted failures are complete Request failed records for thread/read, source=thread_hydration, priority=background, code=-32003, message="thread access denied". Corresponding response_routed records are not counted again.

   The one cache intervention removed only electron-persisted-atom-state.cloud-aeon-sidebar-cache-v1 from the two global-state files while the app was closed. Backups, parsed-state preservation, and file ACLs were checked. The cache stayed absent but denied reads returned. On the phone hotspot, Ethernet was disconnected and the laptop's active route used Wi-Fi with a different gateway. The same denied IDs still recurred.

   An affected original cloud chat was missing from sidebar/search while list_threads and read_thread(hostId="durable") could retrieve it. The built-in thread-ID-only navigation selected hostId=local and failed with "no rollout found". A registered app link explicitly specifying hostId=durable then completed thread/read, turns/items reads, and resume; the user confirmed the original messages were visible. No further denials for that chat were observed in the following three-minute check; 87 others continued. That is a limited opening workaround, not a repair of the catalog.

   Current-build read-only source inspection found the same path described here: cloud-aeon-sidebar-threads calls hydratePinnedThreads with throwOnReadError; BGn preserves only an existing numeric status; retry predicate dv accepts errors without a numeric status; the failed query can refetch every minute. The real catalog warning at 16:00:30.695Z logged status=undefined. An offline probe of the installed pure retry functions accepted a synthetic -32003 error at failure counts 0, 1, and 2, rejected it at 3, and rejected numeric HTTP 403 immediately. This establishes retry classification, not the server's reason for the first denial or the caller of every request.

   Transport errors remain a separate question. The app logged ERR_SSL_BAD_RECORD_MAC_ALERT after restart, before the hotspot test. Ten public HTTPS downloads succeeded on each network; no new TLS/remote-offline/unknown-stream error was observed in the five-minute hotspot window. A read-only request through the desktop connection also succeeded. The user has avoided normal laptop-desktop integration because of the failures, so this is not a sustained workload or reliability validation.

   Please provide a current Windows fix or supported recovery procedure that preserves original chats and active work, and investigate catalog host/access propagation and retry classification. This report does not establish that the denial loop causes all disconnects.

   Only text observations, versions, counts, and sanitized error messages are included. No private thread/request/account IDs, chat titles or contents, personal paths, credentials, raw logs, screenshots, or app-state backups are attached.
9. aiyouwei-laoshu commented on Oct 18, 2026

   

   aiyouwei-laoshu

   on Oct 18, 2026 – with ChatGPT Codex Connector

   More actions

   Additional macOS confirmation on 2026-10-18: supported cloud reads succeed while background hydration continues to report access denied.

   Environment: desktop version 26.1013.40934, build 20770, production channel. The configured updater reported up_to_date during this diagnostic pass. This is an existing-profile observation, not a clean-install reproduction.

   Observed results:

   • The recent background-denial set contained 10 cloud threads.
   • All 10 returned successfully through the supported read_thread tool with hostId="durable". This establishes successful access through that read path, not complete historical recovery or verified UI rendering.
   • After those direct reads, a bounded two-minute log sample still contained 60 Request failed events covering those same 10 targets. This is a log-event count, not a daily total, a count of model turns, or an independently deduplicated count of request IDs.
   • The recurring failure fields were method=thread/read, source=thread_hydration, priority=background, error.code=-32003, error.message="thread access denied".

   No incorrect local host/ownership mapping was found for the sampled targets. That does not establish which authorization context or request parameter differs between the successful and failing paths. No failing wire payload was captured, and no single owner/shared-access explanation is asserted.

   Separate transport disconnections were observed earlier; the cloud connection subsequently recovered and a supported cloud read succeeded. Those transport errors should not be conflated with the continuing background access-denied responses.

   This diagnostic pass did not restart the app, clear caches, modify installed code or signatures, change credentials/configuration/authorization policies, or delete/archive chats. Earlier update/cache-refresh attempts on this installation had not resolved the recurring denial; no cache reset or restart was repeated in this pass.

   Please investigate the successful direct-read versus failing background-hydration context, bound repeated retries of authorization failures, and provide a supported recovery procedure that preserves original chats, configuration, and active work. Related: #53178 and #51675.

   Privacy: this comment contains only sanitized text and aggregate measurements. No files, screenshots, raw logs, conversation contents/titles, private chat/request/account identifiers, credentials, configuration files, or personal filesystem paths are attached or included. Submitted with the user's explicit authorization.