Error creating chat {"value":{},"source":"owned","hooks":[],"promises":[]} message frequently

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

• #39679
• #39672
• #39513
• #39226

Powered by Codex Action

Independent Windows reproduction with additional diagnostics.

Environment

• Windows Codex App package: 26.818.5229.0
• App release recorded in desktop logs: 26.818.41509

Observed behavior

After the app has been running for some time, submitting a follow-up prompt to a completed local chat shows:

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

Once this state begins, subsequent local follow-ups continue failing until the entire desktop app process is restarted.

Sanitized evidence

• Four consecutive failures occurred between 2026-08-23 19:56:00 and 19:56:35 (Asia/Shanghai).
• Across recent desktop logs, I found 15 identical composer failures.
• Every occurrence was logged as followUp=local mode=local.
• A failing submission reaches the local codex-home preflight request, but there is no corresponding turn/start.
• After the first failure in an affected process lifetime, no successful turn/start occurs until app restart.
• The local project directory still exists and Git remains readable, so this is not caused by a missing workspace.
• Background remote-connection retry churn and conversation-state misses were occurring around the failure window and may increase the likelihood of the race, but all affected submissions themselves were local follow-ups.

The displayed JSON looks like serialization of a disposed internal Cap'n Web RPC ownership/promise wrapper rather than an actionable user-facing error. This is consistent with the broader renderer/app-RPC failure described in #39226.

Expected

A completed local chat should accept follow-up turns. If preflight fails, the app should expose the real actionable error and recover without requiring a restart.

Actual

The follow-up fails before turn/start, exposes an internal RPC wrapper, and leaves subsequent local follow-ups broken until restart.

No raw logs, host names, IP addresses, private-key paths, repository paths, task IDs, or user content are included.

Independent macOS reproduction, with a recurring pattern around long-running chats that have been using scheduled tasks.

Environment

• Codex Desktop release: 26.818.41509
• Bundled app-server: 0.149.0-alpha.4.1
• macOS: 26.5.2 (build 25F84)

Observed behavior

After a chat has been running for a long time and scheduled tasks have been active in the workflow, the composer can stop accepting new messages. This affects both normal message submission and attempts to steer an active task.

The UI marks the submission as Failed, and it cannot be retried. Attempts may also show:

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

Once this state begins, repeated submissions and steering attempts keep failing. Fully quitting and restarting Codex restores message entry temporarily; I have not found an in-app recovery.

Reproduction pattern

The trigger is intermittent rather than deterministic:

1. Keep Codex running with a long-lived chat.
2. Use scheduled tasks/automations in that workflow over an extended period.
3. Return to the chat and either submit a new message or steer the active task.
4. The submission is marked Failed and cannot be retried; the opaque owned/hooks/promises error may also appear.
5. Further message and steering attempts fail until the whole Codex app is shut down and restarted.

Sanitized diagnostics

In one affected process lifetime on 2026-08-24, local Desktop logs recorded six [Composer] submit failed events with this exact error between 17:28:52Z and 17:31:02Z. The same internal value also appeared on config-requirements, local-conversation prewarm, and local-task creation paths during the failure window. No raw logs, task content, thread IDs, or local paths are included here.

Expected behavior

Long-running chats and scheduled-task activity should not poison the composer or related app RPC state. Normal messages and steering requests should submit reliably. If a transient failure occurs, the failed submission should be retriable, Codex should recover without requiring a full app restart, and the UI should surface an actionable error rather than an internal ownership/promise object.

I’m seeing this same issue repeatedly in Codex Desktop when trying to send messages:

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

Quitting Codex and signing back in restores it temporarily, but the error keeps returning. It is intermittent rather than a one-off failure and is disrupting normal message sending. I also have a screenshot of the exact popup if useful.