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

What version of the Codex App are you using?

Codex Desktop for Windows:

OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0

The regression began immediately after updating from 26.810.7004.0.

What platform is your computer?

Windows 11 Pro x64
10.0.26200

What issue are you seeing?

After updating Codex Desktop from 26.810.7004.0 to 26.814.5167.0, the renderer intermittently enters a state where composer submissions and several unrelated local app RPC actions fail with the same opaque serialized error:

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

This affects both:

a follow-up submitted while a local turn is running; and
creation of a new local task.

Once the state appears, config reads, permission-mode updates, thread synchronization, prewarming, and conversation resume/history actions can also fail with the same value. The app-server process remains alive and continues responding to some requests.

The failure reproduced in two separate Desktop process lifetimes after normal quit/reopen. A third fresh process has not failed yet, so the trigger is intermittent.

Steps to reproduce

The exact timing trigger is not yet deterministic, but the observed sequence is:

Update Codex Desktop for Windows from 26.810.7004.0 to 26.814.5167.0.
Open an existing local task and let a turn run.
Submit an additional message while the turn is running.
The composer sometimes rejects it with an “Error creating chat/task” toast whose details are the JSON value above.
Try creating a new local task or opening settings. These operations may then fail with the same error.
Quit Codex normally and reopen it. The failure can recur in a later process lifetime.

Expected behavior

A message submitted during a running local turn should be queued or used to steer the turn according to the selected follow-up behavior.
A transient failure in one request should not poison unrelated renderer/app RPC operations.
Errors should be actionable strings or structured error codes, not an internal ownership/promise object.
The renderer should recover without requiring an application restart.

Actual behavior

Sanitized excerpts from one affected process:

2026-08-18T12:12:55.921Z [Composer] submit failed
error={"value":{},"source":"owned","hooks":[],"promises":[]}
followUp=local mode=local

2026-08-18T12:15:36.001Z Error creating local task
error={"value":{},"source":"owned","hooks":[],"promises":[]}

2026-08-18T12:15:43.818Z Error creating local task
error={"value":{},"source":"owned","hooks":[],"promises":[]}

Before and between these failures, the same app-server connection still routed successful responses for other requests. The identical error also appeared on config requirements, layered config, pinned-thread synchronization, permission mode, prewarm, and resume/history paths.

A previous affected process produced the same error cluster beginning at 2026-08-18T11:05:19Z, so this is not a single stale renderer instance.

Runtime disclosure / control variable

This installation launches Desktop with a process-local CODEX_CLI_PATH override pointing to a locally built codex-cli 0.148.0-alpha.9 based on upstream source, with a focused direct-child delegation/join patch. The same pinned CLI and configuration worked before the Desktop update to 26.814.5167.0; the regression appeared only after the Desktop update.

A bundled-CLI A/B run has not yet been completed, so the override is disclosed as a possible compatibility variable. However, the observed failure is broader than the patched collaboration path: it affects new-task creation, config, permissions, thread sync, and resume/history in the Desktop renderer.

Additional information

No raw logs, local paths, thread IDs, or user content are included.
A screenshot and a larger sanitized timeline can be supplied if useful.
The public ChatGPT/Codex changelog currently has no entry for Desktop 26.814.5167.0.

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:

turn-diff-capture-start repeatedly reported Git snapshot became stale.
Failed to start visualization turn diff snapshot was the first operation to return:
```
{"value":{},"source":"owned","hooks":[],"promises":[]}
```
Composer submissions then failed with the same object.
Layered configuration reads, conversation resume/history, thread synchronization, and other unrelated renderer/app RPC operations subsequently failed with the same value.
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:

cloudflare/capnweb#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:

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.
Recreate the renderer/main RPC session after an abort instead of allowing one failure to permanently break unrelated Desktop operations.
Ensure stale Git or visualization snapshots cannot poison the shared RPC transport.
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.

@drawstarAi

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

Follow-up with another reproduction on Windows Desktop 26.820.71523 after using the workaround:

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

This setting was clearly helpful, but it did not eliminate the issue.

Before enabling it, the failure consistently reproduced after approximately 17–21 minutes of Codex process uptime.

With last-turn-only enabled, the latest affected process remained healthy for roughly:

2h 04m before the first owned/hooks/promises occurrence
2h 05m before the first Composer submission failure

So this workaround appears to substantially delay the failure, but not permanently fix it.

Latest failure sequence

The newest reproduction again followed the same general pattern:

turn-diff capture starts
→ visualization turn-diff snapshot receives:

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

→ Git snapshot/add also reports Windows path-too-long errors
→ main renderer config requirements begin returning the same object
→ Composer submissions fail with the same object
→ failed messages never create a corresponding turn/start

The app-server itself still appears healthy during the broken state:

50 normal RPC responses were routed successfully in the inspected window
all had hadPending=true
thread/turns/list continued succeeding
existing running tasks continued producing output
no app-server crash, panic, transport disconnect, response_orphaned, or No promise for request ID was observed

This makes a complete renderer ↔ app-server transport disconnect less likely.

The failure currently looks more like a shared main-renderer async/config/request-preparation state becoming corrupted, while lower-level app-server RPC routing remains functional.

Additional user-visible failures in the same broken state

This reproduction also exposed a wider failure surface than before.

Stop control fails

A running task continued executing, but clicking Stop produced a user-facing:

Failed to stop chat

No turn/interrupt / turn/cancel request was recorded in the affected window.

This suggests the Stop action may also be failing before reaching the app-server, although the exact failure point is not logged.

Conversation detail becomes blank

The left-side conversation list remained visible, but opening some conversations displayed an empty main content area.

For one affected conversation, thread/turns/list still returned successfully in about 8 ms with:

errorCode=null
hadPending=true

So the backend did return the conversation detail request.

The failure therefore appears to be later in the renderer-side state merge / turn-item mapping / hydration / rendering path rather than the app-server failing to return history.

Cross-thread sending fails

Later in the same broken process, an existing task attempted to use:

send_message_to_thread

The dynamic tool request reached the Desktop tool broker / renderer, but failed before creating a target turn/start.

The relevant sequence was:

send_message_to_thread
→ Failed to load config requirements
→ Failed to read service tier for request
→ same owned/hooks/promises object
→ tool result success=false

Basic calls such as thread/read, account/read, and auth status continued to work at the same time.

This further suggests that the failure affects shared renderer-side request preparation/config state rather than the entire app-server transport.

Another possible early signal

The latest affected window also contained a large number of:

Item not found in turn state

errors before the first owned/hooks/promises occurrence.

In the inspected window there were:

Item not found in turn state: 76
owned/hooks/promises: 55
Composer submit failures: 5
config requirements failures: 48 log entries
visualization snapshot owned errors: 2
normal routed RPC responses: 50
403: 0
5xx: 0
Cloudflare challenge: 0
app-server crash/panic: 0

At this point, my working interpretation is:

git-review-mode = "last-turn-only" is an effective mitigation because it greatly increases time-to-failure.
Git/visualization snapshot activity still appears correlated with the first owned error and may be a trigger or amplifier.
The deeper issue may be a shared main-renderer async/config/request-preparation state bug rather than a full RPC transport disconnect.
Once the state is corrupted, it can affect Composer, Stop/control actions, conversation rendering, and send_message_to_thread, while lower-level app-server operations continue to work.

I’ll keep the workaround enabled and can provide another sanitized timeline if useful.

Navigation Menu

Repository navigation

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

What version of the Codex App are you using?

What platform is your computer?

What issue are you seeing?

Steps to reproduce

Expected behavior

Actual behavior

Runtime disclosure / control variable

Additional information

Environment

Behavior

Troubleshooting and control test

Sanitized desktop log sequence

Environment

User-visible behavior

Sanitized excerpts from three logs

Environment

Reproduced failure sequence

First recovery attempt

Second occurrence and additional investigation

Current reversible mitigation

First post-restart verification

Suggested product-side fixes

Latest failure sequence

Additional user-visible failures in the same broken state

Stop control fails

Conversation detail becomes blank

Cross-thread sending fails

Another possible early signal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using?

What platform is your computer?

What issue are you seeing?

Steps to reproduce

Expected behavior

Actual behavior

Runtime disclosure / control variable

Additional information

Activity

captainrock6 commented on Aug 19, 2026

Environment

Behavior

Troubleshooting and control test

Sanitized desktop log sequence

lukwaiyip-ai commented on Aug 20, 2026

Environment

User-visible behavior

Sanitized excerpts from three logs

jyongchul commented on Aug 21, 2026

ITFinesse commented on Aug 21, 2026

shenqiu9355 commented on Aug 22, 2026

Environment

Reproduced failure sequence

First recovery attempt

Second occurrence and additional investigation

Current reversible mitigation

First post-restart verification

Suggested product-side fixes

drawstarAi commented on Aug 27, 2026

drawstarAi commented on Aug 27, 2026

u2bo commented on Aug 28, 2026

drawstarAi commented on Aug 29, 2026

Latest failure sequence

Additional user-visible failures in the same broken state

Stop control fails

Conversation detail becomes blank

Cross-thread sending fails

Another possible early signal

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions