Windows app: every completed turn fails with "This turn couldn't render"

Open 💬 3 comments Opened Aug 20, 2026 by mrmorrandir

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

In the Codex Windows app, every completed turn ends with "This turn couldn't render".

The request itself appears to work: the UI shows Thinking, then briefly streams a few tokens, but when the turn completes the rendered message is replaced by the error card.

This affects old threads, new threads, project chats, and a completely new chat with no project context.

Environment

Codex Windows app version: 26.814.5167.0
Package: OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
Codex CLI on the same machine works correctly.

Reproduction

Open Codex Windows app.
Start a completely new chat with no project/repository context.
Send a trivial prompt such as: Antworte ausschließlich mit dem Wort Hallo.
Observe Thinking and some streamed output.
When the turn completes, the message changes to "This turn couldn't render".

The same happens for existing conversations: thread/project metadata is visible in the sidebar, but every individual turn fails to render.

Troubleshooting already tried

Fully restarted the app.
Tested multiple existing chats and projects.
Tested a brand-new chat without project context.
Renamed the app's LocalCache folder under the MSIX package data directory so Codex had to rebuild it from scratch.
Confirmed that Codex created a fresh LocalCache and fresh desktop logs after restart.
Problem remains unchanged after the cache reset.

Expected behavior

Completed turns should remain visible after streaming finishes.

Actual behavior

The turn is replaced by:

This turn couldn't render

with a Try again button.

Additional observation

Because streaming starts successfully and the CLI works on the same machine, this looks more like a Windows desktop rendering/client regression than a general API/auth/network failure.

Logs are available from the freshly recreated Codex desktop log directory if useful for diagnosis.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 8 days ago

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

#38924

Powered by Codex Action

mrmorrandir · 8 days ago

Not a duplicate.

Ccat-Q · 6 days ago

Confirmed duplicate of #39949 (same root cause). I'm closing #39949 in favor of this one. Sharing the exact root-cause evidence here since it should help pin this quickly:

Confirmed also on 26.818.3698.0 / app-server 0.149.0-alpha.4 (newer build still affected).

Exact renderer error (from error boundary event):

errorMessage: "Cannot read properties of undefined (reading 'enable_message_feedback')"
componentStack: "... at JS (subagent-activity-chip-group-CEtIMCfG.js:13:11232) ... at Gi (local-conversation-turn-BBMTaze8.js:1:11992) ..."

A/B control (same account, same network):

Desktop app (brand-new conversation): fails.
Browser chatgpt.com/codex: identical conversation renders fine.

Data-contract mismatch — the desktop pipeline's response item for the crashing turn (redacted):

{
  "type": "response_item",
  "payload": {
    "type": "message",
    "content": [ { "type": "output_text", "text": "ok" } ],
    "phase": "final_answer",
    "internal_chat_message_metadata_passthrough": {
      "turn_id": "01a024ab-...",
      "create_time": 1787321625.123
    }
  }
}

internal_chat_message_metadata_passthrough contains only turn_id/create_time — enable_message_feedback is absent. The renderer dereferences it without a null-guard. The web path includes the field, so it's the bundled app-server (codex-cli 0.149.0-alpha.4) dropping it when serializing response items for the desktop UI.

Suggested fix: include enable_message_feedback in the app-server's per-message metadata passthrough, or add a null-guard in subagent-activity-chip-group.