codex - 💡(How to fix) Fix Codex Desktop mini window popout renders Application Error on macOS 26.4 [4 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#18311Fetched 2026-04-18 05:56:18
View on GitHub
Comments
4
Participants
1
Timeline
7
Reactions
1
Author
Participants
Timeline (top)
commented ×4labeled ×2closed ×1

On Codex Desktop for macOS, the thread mini-window/popout no longer renders the conversation. It opens a popout window, but the popout immediately displays the app error boundary instead of the thread content.

Local investigation also found a separate terminal-font issue in the same app install: the terminal was configured to use Geist Mono, but that font was not installed locally, so it silently fell back to another monospace font. Installing font-geist-mono resolves that local font issue.

Error Message

Error: Thread context is unavailable for non-thread routes React ErrorBoundary Error

Root Cause

On Codex Desktop for macOS, the thread mini-window/popout no longer renders the conversation. It opens a popout window, but the popout immediately displays the app error boundary instead of the thread content.

Local investigation also found a separate terminal-font issue in the same app install: the terminal was configured to use Geist Mono, but that font was not installed locally, so it silently fell back to another monospace font. Installing font-geist-mono resolves that local font issue.

Fix Action

Fix / Workaround

  • The mini-window action dispatches open-thread-overlay with hostId, conversationId, and title.
  • It then calls maybe-resume-conversation and broadcast-conversation-snapshot for the selected conversation.
  • The overlay route is /thread-overlay/:conversationId.
  • The overlay route component renders the thread content with allowMissingConversation: true and showExternalFooter: true.
  • A route matching helper does recognize /thread-overlay/:conversationId as having a conversation id.
  • However, the runtime error indicates that a component or hook below the overlay route is still calling thread-context-only code while the current route is considered a non-thread route.

Code Example

Error: Thread context is unavailable for non-thread routes
React ErrorBoundary Error

---

app://-/assets/index-kiOLixS3.js
app://-/assets/use-model-settings-DxAqUfLj.js
app://-/assets/vscode-api-BM-wzBx9.js
app://-/assets/app-server-manager-signals-AIlnLWLG.js

---

/Applications/Codex.app/Contents/Resources/app.asar

---

webview/assets/index-kiOLixS3.js

---

"Thread context is unavailable for non-thread routes"
"Open in mini window"
"thread-overlay"
"popout"

---

"Geist Mono", ui-monospace, "SFMono-Regular"

---

brew install --cask font-geist-mono
fc-list | rg -i 'Geist Mono|GeistMono'
RAW_BUFFERClick to expand / collapse

Summary

On Codex Desktop for macOS, the thread mini-window/popout no longer renders the conversation. It opens a popout window, but the popout immediately displays the app error boundary instead of the thread content.

Local investigation also found a separate terminal-font issue in the same app install: the terminal was configured to use Geist Mono, but that font was not installed locally, so it silently fell back to another monospace font. Installing font-geist-mono resolves that local font issue.

Environment

  • App: Codex Desktop from /Applications/Codex.app
  • Codex app version: 26.415.21839
  • CFBundleVersion: 1763
  • Bundle id: com.openai.codex
  • macOS: 26.4 / build 25E246
  • Hardware: Apple M4, arm64
  • Electron: 41.2.0
  • Chrome: 146.0.7680.179
  • Node: 24.14.0
  • Sentry release in local scope: [email protected]
  • Tags in local Sentry scope: buildFlavor=prod, bundle=webview, host=app, preRelease=false
  • Active app-server process: /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

There is also an older ~/Applications/Codex.app at 26.409.20454, but the running process is the newer /Applications/Codex.app build above.

Reproduction steps

  1. Open a local Codex Desktop thread.
  2. Use the thread action to open the mini window / popout.
  3. Observe the popout window.

Expected behavior

The popout should render the selected thread in the mini-window view.

Actual behavior

The popout opens, but it shows the app's error boundary / Application Error message instead of thread content.

The local Sentry scope captured this renderer error:

Error: Thread context is unavailable for non-thread routes
React ErrorBoundary Error

The stack in the Sentry scope points into the production webview bundle, including:

app://-/assets/index-kiOLixS3.js
app://-/assets/use-model-settings-DxAqUfLj.js
app://-/assets/vscode-api-BM-wzBx9.js
app://-/assets/app-server-manager-signals-AIlnLWLG.js

Investigation notes

I extracted the running app bundle from:

/Applications/Codex.app/Contents/Resources/app.asar

The relevant compiled webview bundle is:

webview/assets/index-kiOLixS3.js

From the extracted production bundle:

  • The mini-window action dispatches open-thread-overlay with hostId, conversationId, and title.
  • It then calls maybe-resume-conversation and broadcast-conversation-snapshot for the selected conversation.
  • The overlay route is /thread-overlay/:conversationId.
  • The overlay route component renders the thread content with allowMissingConversation: true and showExternalFooter: true.
  • A route matching helper does recognize /thread-overlay/:conversationId as having a conversation id.
  • However, the runtime error indicates that a component or hook below the overlay route is still calling thread-context-only code while the current route is considered a non-thread route.

That suggests the regression is likely one of these:

  1. /thread-overlay/:conversationId is missing the same thread context provider used by normal thread routes such as /local/:conversationId or /remote/:conversationId.
  2. A child component now rendered in the overlay path, possibly a footer/model/settings/tooling component, assumes thread context and calls the guarded thread-context hook.
  3. The route classification/helper that gates thread context does not include the overlay route even though the overlay route has a conversationId.

Suggested fix direction

One of the following should fix the popout path:

  • Wrap /thread-overlay/:conversationId in the same thread context provider used by the normal thread routes.
  • Or make overlay-specific children avoid the guarded thread-context hook and use explicit conversationId / hostId props instead.
  • Add a regression test that mounts or navigates to /thread-overlay/:conversationId and verifies it does not render the error boundary.

Duplicate search

I searched open and closed issues/PRs for the exact error string and related mini-window/popout terms and did not find an obvious duplicate for this specific macOS Desktop error:

"Thread context is unavailable for non-thread routes"
"Open in mini window"
"thread-overlay"
"popout"

A related but different issue exists for Windows popout resizing (#16180), but this report is about the macOS popout crashing with the thread-context error.

Related local terminal-font finding

This appears separate from the popout crash, but happened in the same app install.

The app state had the light theme Code font set to:

"Geist Mono", ui-monospace, "SFMono-Regular"

Before installing the font, local font enumeration did not show Geist Mono, so the integrated terminal could not render with the configured font and silently fell back. Installing the font fixed local font resolution:

brew install --cask font-geist-mono
fc-list | rg -i 'Geist Mono|GeistMono'

After installation, Geist Mono is visible under ~/Library/Fonts/ and the terminal should use it after an app/window refresh.

This aligns with the behavior discussed in #10620: the terminal uses the configured Code font. A small product improvement would be to surface a warning or diagnostic when the configured UI/Code font is unavailable on the system.

extent analysis

TL;DR

The most likely fix for the Codex Desktop popout issue on macOS is to wrap the /thread-overlay/:conversationId route in the same thread context provider used by normal thread routes.

Guidance

  • Investigate the thread context provider used by normal thread routes (e.g., /local/:conversationId or /remote/:conversationId) and apply it to the /thread-overlay/:conversationId route.
  • Review child components rendered in the overlay path to ensure they do not assume thread context and instead use explicit conversationId / hostId props.
  • Consider adding a regression test to verify that the /thread-overlay/:conversationId route does not render the error boundary.

Example

No code snippet is provided as the issue does not contain sufficient code details. However, the fix direction suggests modifying the route configuration to include the thread context provider.

Notes

The issue appears to be specific to the macOS Desktop version of Codex, and the suggested fix direction is based on the investigation notes provided. The related local terminal-font finding is separate from the popout crash issue.

Recommendation

Apply the suggested fix direction by wrapping the /thread-overlay/:conversationId route in the same thread context provider used by normal thread routes, as this is the most likely solution based on the investigation notes.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The popout should render the selected thread in the mini-window view.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING