Codex Desktop renderer crashes when opening a thread with blocked goal status

Summary

Opening a Codex Desktop thread whose persisted goal row has status = blocked can crash the renderer. After selecting that thread, the app can stop rendering any session until the window is reloaded/restarted.

This looks like a frontend/backend enum mismatch: the app-server/goal state can contain blocked, but the Desktop composer webview bundle only handles active, paused, budgetLimited, and complete in the thread-goal rendering helpers.

Environment

• Product: Codex Desktop renderer/webview bundle extracted from the current Desktop app
• Observed through an unofficial Linux wrapper around the macOS Desktop bundle, but the failure appears platform-independent because it is in the shared composer webview asset.
• Local goal DB: <CODEX_HOME>/goals_1.sqlite

Reproduction pattern

1. Have a local thread with a row in goals_1.sqlite.thread_goals where:

``text
thread_id = <affected thread id>
status = blocked
``

1. Launch Codex Desktop.
2. Select the affected thread from the sidebar.
3. The selected thread fails to render. In my case, after selecting it, selecting other sessions also stopped rendering until reload/restart.
4. If the app is first opened on a healthy thread, that healthy thread renders normally until the affected blocked-goal thread is selected.

Expected behavior

Codex Desktop should render a blocked goal state gracefully, e.g. with a Goal blocked summary/status label and a safe icon, or at minimum fall back to an unknown-status rendering path. One persisted goal status should not crash the page or poison later thread navigation.

Actual behavior

The composer/thread goal UI does not appear to have a blocked branch. The affected thread crashes the renderer with a React minified error (#130 observed locally), consistent with an undefined component/icon/label being passed into rendering.

Local root-cause notes

In the minified composer bundle, the status-related helpers handled these statuses only:

active
paused
budgetLimited
complete

The local hotfix that made the affected thread render again added blocked handling in the same places as the other thread-goal statuses:

• goal status transition helper: blocked returns null
• collapsed summary label: Goal blocked
• expanded status label: Blocked
• status icon helper: map blocked to a warning/alert-style icon instead of returning undefined

After patching the runtime-served content/webview/assets/composer-*.js, the affected thread rendered with Goal blocked; I could then select another thread and return to the affected thread without a renderer crash.

Why I think this is distinct from existing issues

I found related session-rendering/goal issues, but not this exact persisted-status enum mismatch:

• #22963 is a LocalConversationPage crash, but the reported root cause is parsing Windows cwd="C:\\..." directive content.
• #23235 is about slow resume/goal hydration.
• #24282 is about failing to insert a thread_goals row after setting a goal.

This report is specifically about an existing valid thread_goals row with status = blocked causing the Desktop renderer to crash when the thread is selected.

Privacy note

I am intentionally not attaching raw session JSONL, screenshots, or full local logs publicly because they contain private conversation and filesystem metadata. The key sanitized fact is the persisted goal row status: blocked.