Codex Desktop mini window popout renders Application Error on macOS 26.4

Additional local investigation / candidate fix:

I attempted a local hotfix against the packaged renderer bundle in 26.415.21839. The crash appears to happen during overlay bootstrap because the renderer route scope is computed from window.location.pathname before the initialRoute=/thread-overlay/<conversationId> navigation has settled.

In the packaged bundle, the route-scope classifier in webview/assets/diff-view-mode-CDxb8Wc9.js maps these paths to route kinds:

function p({ pathname, routeTemplate }) {
  const conversationId = match(localThread, pathname)?.params.conversationId
    ?? match('/thread-overlay/:conversationId', pathname)?.params.conversationId
    ?? match(hotkeyThread, pathname)?.params.conversationId;

  if (conversationId != null) {
    return { conversationId, pathname, routeKind: 'local-thread', routeTemplate };
  }
  // ... otherwise home/new-thread/remote/other
}

The desktop main process creates the HUD window with initialRoute:

createWindow({
  appearance: 'hud',
  initialRoute: `/thread-overlay/${conversationId}`,
  ...
})

Other overlay-aware code already checks initialRoute directly, but this route-scope classifier does not. If the packaged app initially loads at / or /index.html with ?initialRoute=/thread-overlay/<id>, the route scope can briefly be home/other instead of local-thread, and thread-context atoms then throw:

Error: Thread context is unavailable for non-thread routes

A local candidate patch was to make the route-scope classifier normalize the bootstrap path through initialRoute before matching thread routes:

function p({ pathname, routeTemplate }) {
  let effectivePathname = pathname;

  try {
    if (typeof window !== 'undefined') {
      const initialRoute = new URLSearchParams(window.location.search).get('initialRoute');
      if (initialRoute && (pathname === '/' || pathname === '/index.html' || pathname === 'index.html')) {
        effectivePathname = initialRoute;
      }
    }
  } catch {}

  const conversationId = match(localThread, effectivePathname)?.params.conversationId
    ?? match('/thread-overlay/:conversationId', effectivePathname)?.params.conversationId
    ?? match(hotkeyThread, effectivePathname)?.params.conversationId;

  if (conversationId != null) {
    return {
      conversationId,
      pathname: effectivePathname,
      routeKind: 'local-thread',
      routeTemplate,
    };
  }

  // continue existing remote/home/new-thread/other logic using effectivePathname
}

I verified this patch is syntactically valid when applied to the extracted bundle and that it changes only the route classifier.

Follow-up from local validation of the workaround on macOS 26.4 / Codex 26.415.21839:

The popout route patch alone was not sufficient for a locally modified macOS app bundle because Electron and hardened runtime enforcement add two more requirements:

1. Contents/Info.plist has ElectronAsarIntegrity for Resources/app.asar. After changing and repacking app.asar, Electron aborts at startup unless this hash is updated to the SHA-256 of the ASAR header JSON.
2. Native modules inside the packed ASAR also need to be signed consistently with the outer app. In this build, node_modules/better-sqlite3/build/Release/better_sqlite3.node and node_modules/node-pty/build/Release/pty.node existed inside the packed ASAR and were still OpenAI-signed. Electron extracts them to temp paths such as /var/folders/.../T/.com.openai.codex.*; dyld then rejects them with mapping process and mapped file (non-platform) have different Team IDs if the outer app has been locally re-signed.

Validated local workaround:

• Patch the route-scope logic to treat ?initialRoute=/thread-overlay/<id> as the effective pathname during compact/popout bootstrap.
• Sign native Mach-O files inside the extracted ASAR tree before repacking (better_sqlite3.node, pty.node, and spawn-helper if present).
• Repack app.asar.
• Update ElectronAsarIntegrity.Resources/app.asar.hash to the SHA-256 of the repacked ASAR header JSON, not the raw file hash.
• Sign loose Mach-O files, nested frameworks/apps, then the outer app with one Team ID.

After that, direct launch succeeded, no new crash report was written, and the runtime-extracted temp better_sqlite3 bundle showed the same TeamIdentifier as the outer app.

Follow-up from local patch testing: the launch/signing side is now separate from the remaining popout error.

The popout error is reproducible as a renderer route-scope mismatch. The compact/popout window can load through app://-/index.html?initialRoute=..., and the route scope classifier can still classify popout routes as other. Components in the popout then read the thread/workspace context atoms and hit:

Thread context is unavailable for non-thread routes

The local patch that should address this has two parts:

1. Extend the route classifier to treat the hotkey popout routes as real app routes:

• /hotkey-window -> home
• /hotkey-window/thread/:conversationId -> local-thread
• /hotkey-window/remote/:taskId -> remote-thread
• preserve the existing initialRoute handling when the actual browser pathname is / or /index.html.

1. Add a defensive fallback in the thread/workspace context atoms so an other route returns the same home/workspace context instead of throwing during compact-window startup or transition. This prevents the red error boundary while still allowing proper thread context when the route is classified correctly.

Local validation after patching the packaged app:

codesign --verify --deep --strict --verbose=2 /Applications/Codex.app
/Applications/Codex.app: valid on disk
/Applications/Codex.app: satisfies its Designated Requirement

The latest local ASAR integrity hash after this route/context patch is:

b4a2293a5baf044de04b6aae5272fc2e04380d2b8eb1bd247ec0a0dfbf516fe7

This is still a local binary patch rather than an upstream source PR, but it narrows the product fix to route classification for compact/hotkey popout windows plus a non-crashing context fallback.

This was fixed with 26.415.30602