[Windows][Desktop 26.814.5167] Composer and app RPC actions intermittently fail with opaque {"source":"owned"} error

Confirmed on a newer Windows package with the same user-visible error and a similar renderer/conversation-routing sequence.

Environment

• Windows 11 x64, build 26200, Korean locale
• ChatGPT/Codex desktop package: OpenAI.Codex 26.814.5517.0
• ChatGPT personal Pro account
• No VPN or system proxy

Behavior

After several local task/turn transitions, composer submission fails with:

{"value":{},"source":"owned","hooks":[],"promises":[]}

Restarting the app restores submission temporarily, but the failure recurs. Signing out and back in does not resolve it.

Troubleshooting and control test

• Microsoft Store reports no newer package available.
• Reset the Windows app package and local app cache.
• Signed out completely and signed back in.
• Installed package status is Ok.
• codex doctor reports ChatGPT HTTP reachable, WebSocket handshake HTTP 101, authentication configured, and local SQLite integrity OK.
• An ephemeral prompt sent through Codex CLI using the same ChatGPT authentication completes successfully.

Sanitized desktop log sequence

desktop_fetch_auth_401 hadToken=true
target="GET https://chatgpt.com/backend-api/accounts/:param/settings"

sa_server_request_failed
errorMessage="{\"detail\":\"Must use workspace account for this operation\"}"
routePattern=/accounts/{account_id}/settings
status=401

AppServerConnection response_routed
method=turn/start
conversationId=<existing-thread-id>

Received turn/started for unknown conversation
conversationId=<different-new-id>

[Composer] submit failed
error={"value":{},"source":"owned","hooks":[],"promises":[]}
followUp=local mode=local

The account ID, local usernames/paths, and conversation IDs were removed. This suggests the issue persists beyond 26.814.5167.0 and is not fixed by package reset or reauthentication. The successful CLI control test also suggests the account and service connection remain usable while the desktop renderer enters the failed state.

Confirmed on macOS with the bundled CLI, with the same {"source":"owned"} failure reproduced in three separate desktop process lifetimes.

Environment

• ChatGPT/Codex desktop: 26.814.41407 (build 6720)
• Embedded app-server/CLI: 0.148.0-alpha.15
• macOS 15.1 (build 24B83), Apple Silicon (arm64)
• Authentication: ChatGPT
• No CODEX_CLI_PATH override

User-visible behavior

Sending a message or creating a new task intermittently fails with:

{"value":{},"source":"owned","hooks":[],"promises":[]}

Once this begins, unrelated renderer/app RPC paths also fail with the same object. Fully quitting the app and signing in again restores operation temporarily, but the issue recurs.

Sanitized excerpts from three logs

Local paths, usernames, task/conversation IDs, and user content were removed.

Process lifetime 1

2026-08-20T02:26:02.126Z Failed to start visualization turn diff snapshot
error={"value":{},"source":"owned","hooks":[],"promises":[]}

2026-08-20T02:27:44.269Z [Composer] submit failed
cwd=<redacted-local-path>
error={"value":{},"source":"owned","hooks":[],"promises":[]}
followUp=local mode=local

2026-08-20T02:28:17.782Z Failed to prewarm local conversation
error={"value":{},"source":"owned","hooks":[],"promises":[]}

2026-08-20T02:28:18.420Z Error creating local task
error={"value":{},"source":"owned","hooks":[],"promises":[]}

Process lifetime 2

2026-08-20T07:01:37.257Z Failed to start visualization turn diff snapshot
error={"value":{},"source":"owned","hooks":[],"promises":[]}

2026-08-20T07:02:32.199Z [Composer] submit failed
cwd=<redacted-local-path>
error={"value":{},"source":"owned","hooks":[],"promises":[]}
followUp=local mode=local

2026-08-20T07:03:40.392Z Failed to load config requirements
error={"value":{},"source":"owned","hooks":[],"promises":[]}

Process lifetime 3

2026-08-20T07:10:26.380Z Failed to start visualization turn diff snapshot
error={"value":{},"source":"owned","hooks":[],"promises":[]}

2026-08-20T07:11:33.317Z [Composer] submit failed
cwd=<redacted-local-path>
error={"value":{},"source":"owned","hooks":[],"promises":[]}
followUp=local mode=local

2026-08-20T07:12:13.264Z Failed to prewarm local conversation
error={"value":{},"source":"owned","hooks":[],"promises":[]}

2026-08-20T07:12:35.613Z Error creating local task
error={"value":{},"source":"owned","hooks":[],"promises":[]}

This macOS reproduction with the bundled 0.148.0-alpha.15 CLI removes the custom-CLI override as a required condition and suggests the regression is cross-platform in the 26.814 desktop train. The repeated sequence begins with visualization/pinned-thread state failures and then spreads to composer, config, prewarm, and task creation paths.

Related Windows reproduction on the newer packaged desktop build 26.818.2441.0: #39677.

The user-visible surface differs (Oops, an error has occurred / returned sign-in UI rather than only the opaque composer object), but the sanitized lifecycle evidence points to the same renderer/app-server state-divergence family:

• package status remains healthy;
• Electron main and bundled app-server remain alive;
• AppServerManager RPC is not connected recurs;
• response_orphaned and No promise for request ID accumulate afterward;
• renderer reload / second-instance launch creates another renderer process but does not recreate the long-lived app-server connection;
• local task records continue growing while the desktop UI is unusable.

This was reproduced after the normal Windows package update from 26.814.5517.0 to 26.818.2441.0. No account identifiers, tokens, task/session IDs, process IDs, private paths, or raw logs are included. Please consider linking the issues if maintainers determine they share the same RPC lifecycle root cause.

this happens in VSCode also, its not just a codex desktop thing. Sorry if thats been said.

I can confirm that this issue also reproduces on a newer Codex Desktop build, and I have now captured two independent failure occurrences plus two recovery attempts.

Environment

• Codex Desktop: OpenAI.Codex 26.818.5229.0
• Codex CLI: codex-cli 0.148.0
• Windows x64: build 26200.9168, version 25H2
• Installed app.asar SHA-256:

C5D839BC9B122B7EF2A2F0F45186B3E5895923DE5B6CEF5253C936FE670C0479

Reproduced failure sequence

In both affected Desktop process lifetimes, the failure followed the same sequence:

1. turn-diff-capture-start repeatedly reported Git snapshot became stale.
2. Failed to start visualization turn diff snapshot was the first operation to return:

``json
{"value":{},"source":"owned","hooks":[],"promises":[]}
``

1. Composer submissions then failed with the same object.
2. Layered configuration reads, conversation resume/history, thread synchronization, and other unrelated renderer/app RPC operations subsequently failed with the same value.
3. The app-server remained alive and continued responding to some direct requests.

This strongly suggests that a failed visualization/Git-diff request can abort or poison a shared renderer-to-main RPC session. Once that happens, the Desktop client does not appear to recreate the session automatically.

The affected process log from the second occurrence has SHA-256:

45A3D1A46AC67CF218EB9068F2B425952276C8D13E00CEB49D133AC6E022EA26

I can provide sanitized excerpts from both process logs if useful.

First recovery attempt

The first local recovery did the following:

• backed up the relevant local state;
• isolated and regenerated only disposable renderer/UI caches;
• set model_reasoning_summary = "none";
• restarted Codex Desktop.

This restored message submission, real backend turn creation, tool calls, database access, and network connectivity. No account, project, conversation, plugin, skill, cookie, IndexedDB, or local-storage data was removed.

However, this was only a recovery, not a fix:

• ResizeObserver errors returned approximately 36 seconds after restart;
• they accumulated to 155 occurrences during the verification window;
• Desktop still resolved the task as summary=detailed;
• concurrentReasoningSummariesFeatureOverrideEnabled=true was still active;
• therefore, model_reasoning_summary = "none" did not disable the Desktop summary/layout path.

The original trigger remained present and the failure later recurred.

Second occurrence and additional investigation

After the same Git snapshot became stale -> visualization snapshot owned error -> shared RPC failures sequence occurred again, I inspected a read-only copy of the installed application package.

The current Codex Desktop package declares capnweb 0.8.0. Its bundled abort path passes the RpcPayload wrapper into the abort handler instead of passing the underlying payload.value.

Cloudflare has already merged a directly relevant correction:

https://github.com/cloudflare/capnweb/pull/190

That PR changes the abort handler to pass payload.value, consistent with the adjacent reject handler.

This appears to explain why Codex Desktop surfaces the opaque serialized object containing source:"owned" instead of the actual abort reason. It may not, by itself, explain the original condition that aborts the RPC session.

Current reversible mitigation

Because both occurrences began in the full Git/visualization snapshot path, I applied this supported Desktop configuration:

[desktop]
git-review-mode = "last-turn-only"

This changes Git Review from the full accumulated change source to only the most recent turn. It does not change the model, reasoning level, permissions, projects, conversations, or user files.

The configuration was validated by codex-cli 0.148.0, and the application was then fully restarted so the Desktop process would load it.

First post-restart verification

After the restart:

• a new user message reached the real backend and created a real turn;
• message submission succeeded;
• the task continued normally;
• project and sidebar state remained intact;
• the compatibility-state test key was not left behind.

During the initial post-restart verification window:

• source:"owned": 0
• visualization snapshot failures: 0
• Git snapshot became stale: 0
• turn-diff-capture-start: 0
• Composer submission failures: 0
• configuration-read failures: 0
• ResizeObserver errors: 0

This is a successful first verification of the workaround, but it is not evidence that the product bug is permanently fixed.

Suggested product-side fixes

A complete fix would ideally include all of the following:

1. Update the bundled Cap'n Web dependency to a version containing the payload.value abort fix, or apply an equivalent patch, so the real error reason is surfaced.
2. Recreate the renderer/main RPC session after an abort instead of allowing one failure to permanently break unrelated Desktop operations.
3. Ensure stale Git or visualization snapshots cannot poison the shared RPC transport.
4. Stress-test:

• repeated stale Git snapshots;
• follow-up messages submitted while a local turn is running;
• creation of new local tasks;
• configuration reads and conversation resume after a snapshot failure.

Changing the visible error from the opaque owned wrapper to a readable message would improve diagnostics, but the renderer must also recover automatically without requiring an application restart.

I can provide a sanitized event timeline, selected log excerpts, verification counts, and hashes without including local paths, thread IDs, user content, or project data.

I’m seeing what appears to be the same regression on a newer Codex Desktop build:

Codex Desktop for Windows: 26.820.71523

The user-facing error is exactly the same on every reproduction:

{"value":{},"source":"owned","hooks":[],"promises":[]}

I have reproduced it three times in one evening, with a surprisingly consistent process-lifetime pattern:

• process start 21:50:54 → first Composer failure 22:08:17.647 (~17m 23s)
• process start 22:31:16 → first Composer failure 22:52:06.366 (~20m 50s)
• process start 23:08:38 → first Composer failure 23:26:33.326 (~17m 55s)

Observed behavior:

• existing running tasks continue normally;
• new Composer submissions fail immediately;
• failed submissions do not create a corresponding turn/start;
• app-server remains responsive after the failure;
• the same owned/hooks/promises object later appears in renderer-side paths such as layered config, config requirements, persisted routes, and visualization turn-diff snapshot.

In the two latest reproductions, the first recorded occurrence of the shared object appeared in:

Failed to start visualization turn diff snapshot

approximately 7–12 seconds before the first Composer failure.

However, I cannot confirm that visualization is the root cause; it may simply be the first renderer consumer to encounter an already-corrupted shared async resource.

The relevant failure windows contained:

• 403: 0
• 5xx: 0
• Cloudflare challenge: 0
• sentinel/heartbeat errors: 0
• app-server crash/panic: 0

The only recurring HTTP errors were workspace settings requests returning:

401 Must use workspace account for this operation

but successful turn/start events also occur while those 401s are present, so they do not appear to be the direct cause.

A full Windows reboot did not prevent recurrence.

This looks like the same renderer / async-resource state regression described here, and it appears to still be present in 26.820.71523.

Follow-up after applying the reversible workaround discussed above.

I changed only:

[desktop]
git-review-mode = "last-turn-only"

and then fully restarted Codex Desktop.

Visualize remained enabled, and I continued the same normal UI/prototype workflow across multiple conversations. I did not disable visualization, change projects, sign out, reset the app, or modify the network configuration.

Before this change, the failure reproduced three times with a very consistent process-lifetime window:

• ~17m 23s
• ~20m 50s
• ~17m 55s

After switching to last-turn-only, Codex has now remained stable for several hours of continued use with:

• no Composer submission failures;
• no user-facing {"value":{},"source":"owned","hooks":[],"promises":[]} popup;
• no need to restart Codex;
• Visualize still functioning normally for HTML/UI work.

This is not proof of the root cause or a permanent fix, but it is a strong independent confirmation that reducing the Git Review / turn-diff scope can avoid or substantially delay the failure on Windows Desktop 26.820.71523.

Given the earlier logs where Failed to start visualization turn diff snapshot was often the first consumer to surface the shared owned/hooks/promises object, this makes the full accumulated Git/turn-diff snapshot path look increasingly likely to be a trigger or amplifier of the renderer/RPC state failure.

I’ll continue using this configuration and will update again if the issue recurs.
@drawstarAi

same error 26.820.80927 version win 11