Codex Desktop mini window popout renders Application Error on macOS 26.4

Resolved 💬 4 comments Opened Apr 17, 2026 by StuartAJ Closed Apr 17, 2026

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: codex@26.415.21839
  • 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.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗