[Windows Desktop 26.1007.21434] Renderer exceeds 10 GiB and freezes; persistent retries of denied hydration

Entorno comprobado el 11 de octubre de 2026:

Windows 11 Home, build 26200, x64, aproximadamente 32 GB RAM.
Codex Desktop producto 26.1007.21434, build 13901, canal prod.
Paquete MSIX 26.1007.2314.0; backend 0.162.0-alpha.17.2.
Comprobador de actualizaciones: up_to_date. No significa que el fallo esté corregido.

Observación local:
La interfaz vuelve a congelarse después de responder normalmente. La misma instancia del renderer, iniciada el 9 de octubre, pasó de aproximadamente 617 MiB a más de 10,281 MiB de memoria privada el día 11. No se atribuye ese proceso a un proyecto individual: es la interfaz principal de Codex.
En muestras posteriores de esa misma instancia, sin reiniciarla ni cerrarla, bajó a 852 y 864 MiB, y después a unos 826 MiB. Esto impide afirmar una fuga estrictamente monotónica o una relación causal demostrada entre cada error y la memoria retenida.

Falla reproducida en registros:
En los archivos retenidos de esa instancia se contaron 103,964 líneas de rechazo thread access denied para 15 identificadores repetidos. Son líneas de error, no una medida de tokens, facturación ni 103,964 tareas ejecutadas.
Firma: method=thread/read, source=thread_hydration, priority=background, error code=-32003. Los rechazos continúan después de bajar la memoria.
Una inspección acotada posterior de seis colas de logs (máximo 4 MiB por archivo) encontró 16,781 rechazos y siete errores ResizeObserver. No sumar este conteo al anterior: hay solapamiento.
Mediante lecturas oficiales de tareas, diez de los quince destinos fueron accesibles mientras la interfaz los rechazaba: siete completados/inactivos y tres contenedores inactivos sin turnos. Otros cinco no fueron accesibles tras dos intentos. No se concluye que estén eliminados ni que haya quince servidores activos.

Contraste público consultado:
#53178
Describe reintentos de hidratación denegada en macOS, también después de reiniciar. Coincide la firma, no la plataforma; no demuestra causa común del heap.
#51572
Reporte de reintentos de hidratación denegada en Windows.
#52129
Contraste entre lecturas directas exitosas y acceso desde la interfaz fallido a historial cloud.
#52827
Misma versión Windows, lentitud y ResizeObserver; su autor tampoco establece causalidad mediante perfil.
#38059
Otro usuario vinculó crecimiento en reposo con la mascota. En este equipo su estado efectivo no está confirmado; no se aplica ese resultado como diagnóstico.

Solicitud concreta al fabricante:

Proporcionar un método soportado para capturar perfil de CPU/heap del renderer afectado sin perder chats ni reiniciar el perfil.
Investigar preservación del modo de acceso autorizado durante thread_hydration y la política de reintentos tras -32003. No evadir los controles de autorización del servidor.
Proporcionar corrección o mitigación soportada y reversible que detenga reintentos inútiles sin borrar historial cloud/local, tareas ni configuración.
Indicar versión corregida y prueba de regresión para crecimiento/congelamiento durante reposo prolongado.

Límites y privacidad:
No hay captura de heap ni traza simbolizada que identifique la función retenedora. No se afirma que los errores ResizeObserver, la mascota o el bucle de lecturas expliquen por sí solos todos los congelamientos. No se modificaron ejecutables, SQLite, credenciales, modelo, proyectos ni caché. No se cerraron procesos para este contraste. No se adjuntan logs brutos, identificadores privados, rutas personales, correos, conversaciones ni secretos.
Estado: evidencia local verificada; causa exacta del pico pendiente; corrección no aplicada.

Preparado y enviado por Codex en nombre del usuario, con su autorización explícita. Se solicita al equipo consolidar con los reportes relacionados si se confirma una causa común.

English translation:

Environment verified on October 11, 2026:

Windows 11 Home, build 26200, x64, approximately 32 GB RAM.
Codex Desktop product version 26.1007.21434, build 13901, prod channel.
MSIX package 26.1007.2314.0; backend 0.162.0-alpha.17.2.
Update checker: up_to_date. This does not mean the bug has been fixed.

Local observation:
The interface freezes again after responding normally. The same renderer instance, started on October 9, went from approximately 617 MiB to more than 10,281 MiB of private memory on the 11th. That process is not attributed to an individual project: it is the main Codex interface.
In later samples of that same instance, without restarting or closing it, memory dropped to 852 and 864 MiB, and then to about 826 MiB. This prevents asserting a strictly monotonic leak or a proven causal relationship between each error and retained memory.

Failure reproduced in logs:
The retained files from that instance contained 103,964 thread access denied rejection lines for 15 repeated identifiers. These are error lines, not a measure of tokens, billing, or 103,964 executed tasks.
Signature: method=thread/read, source=thread_hydration, priority=background, error code=-32003. The rejections continue after memory drops.
A later, limited inspection of the tails of six log files (a maximum of 4 MiB per file) found 16,781 rejections and seven ResizeObserver errors. Do not add this count to the previous one: they overlap.
Through official task reads, ten of the fifteen targets were accessible while the interface was rejecting them: seven completed/inactive and three inactive containers with no turns. Another five were not accessible after two attempts. This does not establish that they have been deleted or that there are fifteen active servers.

Public reports consulted for comparison:
#53178
Describes retries of denied hydration on macOS, including after restarting. The signature matches, but the platform differs; this does not demonstrate a common cause of the heap growth.
#51572
Report of retries of denied hydration on Windows.
#52129
Comparison between successful direct reads and failed access to cloud history from the interface.
#52827
Same Windows version, slowness, and ResizeObserver; its author also does not establish causality through profiling.
#38059
Another user linked growth while idle to the mascot. Its actual state on this machine is unconfirmed; that result is not being used as a diagnosis.

Specific request to the vendor:

Provide a supported method to capture a CPU/heap profile of the affected renderer without losing chats or resetting the profile.
Investigate preservation of the authorized access mode during thread_hydration and the retry policy after -32003. Do not bypass the server's authorization controls.
Provide a supported, reversible fix or mitigation that stops futile retries without deleting cloud/local history, tasks, or settings.
Identify the fixed version and a regression test for growth/freezing during prolonged idle periods.

Limitations and privacy:
There is no heap capture or symbolicated trace identifying the retaining function. No claim is made that ResizeObserver errors, the mascot, or the read loop alone explain all freezes. No executables, SQLite, credentials, model, projects, or cache were modified. No processes were closed for this comparison. No raw logs, private identifiers, personal paths, emails, conversations, or secrets are attached.
Status: local evidence verified; exact cause of the spike pending; fix not applied.

Prepared and submitted by Codex on behalf of the user, with their explicit authorization. The team is asked to consolidate this with related reports if a common cause is confirmed.

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
[macOS Desktop 26.1007.30912] Recent sidebar shrinks to two after launch; active thread reads denied #53193

Powered by Codex Action

Same signature on a newer build, plus a concrete mechanism I was able to isolate. Adding here instead of opening a new issue since the -32003 / thread_hydration / priority=background retry loop matches exactly.

Environment

Codex Desktop Windows MSIX OpenAI.Codex_26.1013.4894.0 (build 26.1013.4894.0), Windows 11 x64
Previous build 26.1007.2314.0 did not show this. The loop appeared immediately after updating to 26.1013.
Signed in, and the account also uses cloud agent (Aeon / Amo) sessions from mobile

Symptom, and why it groups with this issue

Two symptoms toggle together on the same machine:

Startup is slow and shows an error dialog that has to be dismissed with Retry before the app is usable.
Remote control from mobile / tablet intermittently reports conversation load timeout.

Both are consistent with a shared app-server queue being saturated by background hydration retries.

Log signature (identical)

info  [AppServerConnection] response_routed
  broadcastFallback=false conversationId=<id>
  durationMs=102 errorCode=-32003 hadInternalHandler=false hadPending=true
  method=thread/read originWebcontentsId=1 queueWaitMs=1

error [electron-message-handler] Request failed
  conversationId=<id> durationMs=169
  error={"code":-32003,"message":"thread access denied"}
  method=thread/read pendingCountAfter=1 priority=background

hadInternalHandler=false is the important part: the local app-server has no handler at all for these IDs. They are retried every 4–6 seconds, unbounded, with no backoff.

Where the IDs come from — the mechanism

All 12 retried IDs return zero rows from thread_history_1.sqlite (thread_items / thread_turns) and have no rollout file under ~/.codex/sessions/. They exist only in .codex-global-state.json:

electron-persisted-atom-state.cloud-aeon-sidebar-cache-v1
  hostId: "durable"
  refreshStartedAtMs: <10 days stale>
  threads[]:
    source:  {"custom":"codex-cloud-agent"}
    status:  {"type":"notLoaded"}
    turns:   []
    cwd:     /workspace/scratch/<id>     // Linux, cloud container
    ephemeral: false

So the cache already records status.type = notLoaded and hostId = durable, yet the renderer still asks the local thread/read to hydrate them. Composition of the 12:

Kind	Count	`threadSource`	`is_user_visible`
Cloud agent root	2	`aeon`	`true`
Cloud agent child	4	`aeon_child`	`false` (1 `true`)
Dreaming loop	3	`dreaming`	`false`
Other (not in this cache; resolved from a `durable:` host list)	3	—	—

Created between 2026-09-30 and 2026-10-09. The three dreaming entries are internal background loops with turns: [] and no UI surface, so there is no user action that could ever load them — they are guaranteed 100% failure targets, retried forever.

Suspected filter gap

In the (minified) sidebar filtering helper:

function filterThreadKeys({cloudThreadsAllowed, localThreadsAllowed, threadKeys}) {
  return cloudThreadsAllowed && localThreadsAllowed
    ? threadKeys
    : threadKeys.filter(k => {
        switch (kindOf(k)?.kind) {
          case "local":  return localThreadsAllowed;
          case "remote": return cloudThreadsAllowed;
          case undefined: return true;      // <-- unclassified keys pass through
        }
      });
}

If kindOf() does not classify these keys as remote — e.g. because the host id is durable rather than local, or the key carries no host prefix — they survive filtering and are later handed to local hydration. The undefined branch returning true means an unclassifiable key is never filtered out, only retried.

Expected

A thread whose hostId is not the local host, or whose status.type is notLoaded and source.custom is codex-cloud-agent, should not be requested via local thread/read. Either route it to the cloud API, omit it from the local hydration set, or surface a single non-retrying "unavailable in this client" state. An unbounded background retry for a target that can never be served locally should not exist.

Mitigation under test

Removing electron-persisted-atom-state.cloud-aeon-sidebar-cache-v1 from .codex-global-state.json with the app fully quit resets this state. I am verifying whether it stops the loop and will report the before/after count of -32003 lines. Note this is only a local mitigation — the routing issue itself remains, and the cache repopulates.

Privacy

No thread IDs, account identifiers, personal paths, raw logs, or conversation content are included. All counts are log-line counts, not tokens, billed requests, or executed tasks. Diagnosed with agent assistance on sanitized local logs; no SQLite, credentials, projects, or app files were modified.

Possible duplicates to consolidate with: #53178 (macOS, same signature), #51572 (Windows, denied hydration retries), #51675 (cloud tasks missing from sidebar after restart), #52129.

Follow-up: measured before/after, and why a local fix cannot fully stop it

I removed electron-persisted-atom-state.cloud-aeon-sidebar-cache-v1 (9 cloud threads), the 3 thread-tab-routes-v1:<cloud id> keys, and filtered 5 IDs out of unreadByIdentity, with the app fully quit. Verified after writing: 37 of 39 top-level keys are hash-identical — the two that differ are electron-persisted-atom-state (the one I edited) and electron-thread-read-state-v1 (rewritten by the app on launch) — the atom sub-key count went 227 → 223 (exactly the 4 removed keys), and orbit-outputs-v1 was left untouched.

Results after restart

Metric	Before	After
Distinct threads retried	12	5
Startup error dialog	every launch, needs "Retry"	gone
Denied `thread/read` attempts per minute (idle)	~22.6	~14.0
Per-thread retry cadence	1 attempt / ~32 s	1 attempt / ~21 s

Counted from Request failed … error={"code":-32003,"message":"thread access denied"} lines only: 904 attempts over 40 min before, 125 attempts over 8.9 min after. So the startup symptom this issue reports is gone on this machine, and the retry set shrank from 12 threads to 5 — but the per-thread cadence did not change. Only the number of threads changed, which is exactly why the loop is not gone.

Why it cannot be fully fixed locally

Of the 5 remaining IDs:

2 (01a104b8…, 01a0f5d9…) are still referenced by 22 of the 23 entries in orbit-outputs-v1[], plus primary-aeon-selection-v1, aeon-subtasks-by-account-v1, heartbeat-thread-permissions-by-id, prompt-history and two smaller keys. Clearing these would discard the user's Output panel entries, so I left them.
3 (01a123af…, 01a119bf…, 01a119bc…) occur zero times in the whole .codex-global-state.json (405 KB) after the cleanup. I string-searched the file: 0 occurrences each. They are re-supplied at runtime, not read from local state.

That is the part worth looking at on the server side: the retry set is not purely cache-driven. Once the stale cache is gone, the client still learns about cloud-hosted threads from the durable host list and issues a local thread/read for them.

Conclusion for the report

The local cache is a multiplier, not the source: deleting it cut the set of bad threads from 12 to 5, but every remaining thread keeps retrying at the same cadence. If the intent is to stop the loop entirely, the fix has to be in the routing decision — do not issue a local thread/read for a thread whose host is not local / not readable — rather than in cache invalidation. Any suggested workaround of the form "clear the sidebar cache" should be expected to shrink the set, not eliminate the retries.

Numbers above are log-line counts from sanitized logs, not tokens, billed requests, or executed tasks. No thread IDs beyond the first 8 characters, no account identifiers, no personal paths, no conversation content. No SQLite, credentials, or app files were modified; only the four state keys described.

Navigation Menu

Repository navigation

[Windows Desktop 26.1007.21434] Renderer exceeds 10 GiB and freezes; persistent retries of denied hydration #53277

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Windows Desktop 26.1007.21434] Renderer exceeds 10 GiB and freezes; persistent retries of denied hydration #53277

Description

Activity

github-actions commented on Oct 12, 2026

github-actions commented on Oct 12, 2026

kulear829 commented on Oct 18, 2026

kulear829 commented on Oct 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions