›_ Codex Issues
Codex Issues / #34205

Codex Security sidebar and side chat fight for ownership, causing focus loop and React #185

Open 💬 5 comments Opened Jul 19, 2026 by constantins2001
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop / ChatGPT app 26.715.31925 (build 5551), bundle ID com.openai.codex.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

  • macOS 27.0 (build 26A5368g)
  • Apple Silicon / arm64

What issue are you seeing?

A completed Codex Security workspace/sidebar and an ephemeral side chat fight for ownership of the same sidebar/aside surface.

The Codex Security tab cannot be permanently closed. Returning from or closing a side chat causes the completed Security workspace to rehydrate through mcpServer/resource/read and reclaim the parent route. At the same time, the side chat repeatedly toggles active/inactive. The focus/ownership loop ends in the app-wide AppRoutes error boundary with:

Minified React error #185

The source task remains healthy at the app-server level: its JSONL is valid and thread/read returns all completed turns. This is a renderer/resource-lifecycle failure, not transcript corruption, native OOM, or an active security scan.

What steps can reproduce the bug?

  1. Open a local task that has launched a Codex Security workspace.
  2. Complete the security scan. The Security workspace remains available in the sidebar.
  3. Open an execution-side/side chat from that task.
  4. Submit work in the side chat.
  5. Leave or close the side chat and return to the parent task.
  6. Try to close or navigate away from the Codex Security tab.
  7. The Security resource reappears/steals focus, while the side chat repeatedly changes view activity.
  8. The main window enters the AppRoutes error boundary with React #185.

This was reproduced again after recovering the source task into a fork.

What is the expected behavior?

  • Closing or leaving a completed Codex Security workspace should dispose its sidebar ownership until explicitly reopened.
  • A side chat and an MCP App resource must not simultaneously own or repeatedly reclaim the shared sidebar.
  • Leaving a side chat should unregister its view-activity and sidebar bindings before the parent resource is rehydrated.
  • If either panel fails, the failure should remain scoped to that panel and not crash the complete task view.
  • Codex Security should expose a reliable close/dispose workspace lifecycle operation.

Additional information

Sanitized timeline from a reproduction:

17:24:38.737 parent task becomes active; sidebar owner sync targets parent
17:24:38.755 ephemeral side chat becomes active
17:24:38.784 mcpServer/resource/read succeeds for the parent task
17:24:38.830 ephemeral side chat becomes inactive
17:24:38.838 parent sidebar owner sync/rebind repeats
... active=true/false and owner-sync/rebind repeat dozens of times ...
17:24:39.757 AppRoutes error boundary: Minified React error #185

The component stack includes the shared aside subtree.

Diagnostics and workarounds:

  • The scan was already complete, so this is not a progress-update race.
  • The exposed Codex Security MCP surface has open/reopen operations but no close/dispose workspace operation.
  • Archiving the ephemeral side chat does not clear already-bound renderer state.
  • Forking the parent preserves the historical Security workspace/tool record and remains susceptible.
  • Creating a clean normal project task with the recovered prompt, without inheriting the Security workspace record, avoids the collision.
  • No macOS native crash report is produced.

Related but distinct: #32151 reports a generic side-dialog/browser-sidebar rebind loop and was said to be fixed in a subsequent release. This report identifies a remaining plugin-specific lifecycle conflict on the newer 26.715.31925 build: a persistent completed Codex Security MCP resource competes with an ephemeral side chat and cannot be disposed.

Supporting reproduction comments on #32151:

Raw task IDs and full logs are intentionally omitted because the affected task contains security-review material. Targeted sanitized excerpts can be provided if maintainers need more detail.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33994

Powered by Codex Action

hoshimiii · 1 month ago

Windows repro adds a pre-start variant and points to a concrete plugin-side lifecycle gap.

Environment

  • Codex Desktop for Windows: 26.715.10079.0
  • Codex Security plugin: 0.1.11
  • The setup workspace was opened from a local task, but Start scan was never pressed, so no scanId existed.

Reproduction

  1. Ask Codex to run a Codex Security scan.
  2. Let open_codex_security_workspace open the setup workspace.
  3. Before pressing Start scan, stop/cancel the waiting turn or return to the task.
  4. Try to close or navigate away from the Security side panel.

The setup panel remains mounted and has no visible close/cancel action. Navigating back to the task does not dispose it.

Bundle evidence

I inspected the locally installed 0.1.11 MCP App bundle:

  • The setup footer renders only #start (Start scan).
  • The bundled MCP App SDK exposes requestTeardown(), but the application bundle contains no call site for it (only the method definition).
  • #cancel-scan is wired only for states after a scan/handoff exists.
  • The app-only cancel_codex_security_scan tool requires a scanId, so it cannot cancel or close this pre-start setup state.

This means the pre-start setup workspace has neither a plugin-level teardown action nor a scan cancellation path. It is consistent with the persistent sidebar ownership described in this issue, but reproduces before any scan is created.

Expected

The setup footer should include a Close/Cancel setup action that calls ui/notifications/request-teardown (for example through the existing requestTeardown() SDK method). Stopping the waiting turn should also leave the workspace dismissible.

Local workaround verified

I made a reversible local patch to the cached 0.1.11 app resource that adds a Close button to the setup footer and binds it to requestTeardown(); the recompressed resource validates successfully. This is only a local cache workaround and will be replaced by plugin updates, so an upstream lifecycle fix is still needed.

idaibin · 1 month ago

I am seeing a related but earlier lifecycle failure: an unstarted Codex Security setup workspace cannot be dismissed.

Environment:

  • Codex Desktop runtime: 26.715.72359
  • Codex Security plugin: 0.1.11
  • macOS 26.5.2 (25F84), arm64

Sequence:

  1. Open Security setup for an uncommitted working-tree diff.
  2. The page reports that the working-tree contents changed and asks to select the uncommitted changes again.
  3. Do not start the scan. No scanId exists.
  4. Close the Security tab with its ×.
  5. The content disappears briefly, but the tab remains. Selecting it restores the same setup page, and repeated close attempts behave identically.

This occurs without a completed scan, side chat, duplicate workspace, missing artifact directory, or React error. It appears that the pre-start setup resource remains attached after the tab is closed.

There is also no available recovery operation: scan cancellation requires a scanId, while this workspace never progressed far enough to create one.

Expected behavior: closing a pre-start Security workspace should dispose its setup resource and pending session so it cannot reattach until explicitly opened again.

hoshimiii · 1 month ago

Correction and confirmed root cause after a full Codex restart:

  • Environment: Windows Codex 26.715.10079, Codex Security plugin 0.1.11.
  • I added a local setup-page Close control and verified the restarted process re-read the patched MCP app resource.
  • requestDisplayMode({ mode: "inline" }) does not close the Security side-panel tab. It only changes the MCP app display-mode state; the host keeps the side-panel frame/content mounted.
  • The Codex MCP app host bundle has no handler for the standard ui/notifications/request-teardown notification, so App.requestTeardown() is silently ignored.
  • The side panel is actually cleared only through the native tab onClose / closeTab lifecycle.

So the earlier local requestDisplayMode("inline") workaround is disproven. A proper fix needs the Codex host to handle ui/notifications/request-teardown by invoking the same lifecycle as closing the MCP side-panel tab (including resource teardown/unmount).

nagisawr · 25 days ago

I can still reproduce this on the current app version. In my case, closing the Codex Security tab reveals a subagent tab underneath it, and that immediately crashes the task view.

Environment

  • ChatGPT / Codex Desktop app: 26.727.51351 (build 6119)
  • Bundle ID: com.openai.codex
  • Bundled Chromium: 150.0.7871.182
  • MacBook Pro (Mac17,6), Apple M5 Max (18-core)
  • macOS 27.0 (26A5388g), Apple Silicon / arm64
  • ChatGPT Pro

How I reproduce it

  1. Open a local task that has subagents and a Codex Security tab.
  2. Keep the Security tab open. Everything works normally at this point.
  3. Close the Security tab.
  4. Codex automatically switches the side panel back to one of the subagents.
  5. The whole task view immediately shows the full-screen error page.

Opening the task again causes the same error as long as that subagent remains selected in the side panel. If the Security tab is visible instead, the task opens normally.

I reproduced this twice on August 3, 2026. The local Sentry breadcrumbs in ~/Library/Application Support/Codex/sentry/scope_v3.json contain React error #185 at the exact times of the latest crash:

2026-08-03 08:57:35 CEST  Minified React error #185
2026-08-03 08:57:36 CEST  Minified React error #185
2026-08-03 08:57:46 CEST  Minified React error #185
2026-08-03 08:57:50 CEST  Minified React error #185

The stack starts with:

Error: Minified React error #185
    at Kr (app://-/assets/app-initial-iBPGfcXU.js:192:27506)
    at Wr (app://-/assets/app-initial-iBPGfcXU.js:192:27029)

Other details from the logs

  • sky.node repeatedly logs RemoteHostedPIPContent active thread changed while the side panel changes tabs.
  • The ChatGPT process does not actually quit. The Codex task also keeps running and continues executing tools in the background. Only the task view breaks.
  • macOS does not create an .ips crash report, and Codex does not create a new Crashpad dump.
  • After reproducing the bug, the largest Codex renderer was using about 1.55 GB RSS. The other renderers were using roughly 200–490 MB each.
  • The task can still be read through the app server, so its transcript does not appear to be corrupted.

I left out the task IDs and local paths because the affected task contains private project and security-review information. I can provide more sanitized log excerpts if needed.

This bug is therefore still present in 26.727.51351, not only in the older 26.715 builds mentioned above.