Windows Codex app creates duplicate unclosable Security workspaces

Open 💬 2 comments Opened Jul 10, 2026 by TA-matrix-coder

What happened

Opening a final staged-diff Codex Security workspace in the Windows desktop app produced six duplicate/stale Security tabs. The tabs could not be closed with the normal close buttons, tab context menu, keyboard close shortcuts, or Windows UI Automation. Restarting the Codex app was the only successful way to clear the corrupted tab state.

The security scan was not started after the duplication appeared.

Steps to reproduce

  1. In a local Git project with a staged diff, open a Codex Security workspace for the staged changes.
  2. Observe that multiple duplicate Security workspace tabs may open.
  3. Attempt to close the duplicate tabs using the tab close button, context menu, or keyboard shortcut.

Expected behavior

Exactly one Security workspace opens, and it can be closed normally.

Actual behavior

Six duplicate/stale Security workspaces opened and none responded to normal close actions. A full app restart was required.

Environment

  • Windows desktop
  • OpenAI.Codex app version: 26.707.3748.0
  • Codex CLI version: 0.142.5
  • Observed: 2026-07-10

Impact and workaround

This blocked the intended final staged-diff security scan because continuing risked more duplicate workspaces and unclear scan state. Current workaround: restart Codex and avoid reopening Security if duplication recurs.

No project data or session logs are included in this public report.

View original on GitHub ↗

2 Comments

mdotk · 1 month ago

I can reproduce the same user-visible failure on macOS, and the behavior appears broader than a Windows-only or Codex Security-only problem.

Environment

  • macOS
  • Codex Desktop: 26.707.91948 (build 5440)
  • Bundled Codex CLI: 0.144.5
  • Observed: 2026-07-17

Symptoms

  • Multiple duplicate, identically labelled, uncloseable workspace/widget tabs appear inside affected tasks.
  • I have observed this with both Codex Security and the Data Analytics plugin.
  • Reopening an affected task restores the duplicate widgets from task history.
  • There is no visible per-widget close or dismiss action.
  • Some restored widgets remain visible but fail to render or update correctly.
  • Restarting the app can reset the live runtime state, but it does not remove widget results already persisted in task history.

Sanitized diagnostic evidence

  • One Data Analytics task contained two successful render_artifact results. On task reopen, both were mounted as separate Dataanalyticswidget tabs with the same generic label.
  • One Codex Security task contained 16 open_codex_security_workspace calls: 2 create calls and 14 reopen calls. Each UI-producing call was retained as another task result, even though the installed Security workflow says the workspace should be opened once and then update automatically.
  • Desktop logs recorded mcpServer/resource/read failing for a persisted widget with thread not found. A later read could succeed after the task runtime was restored, while the stale tab itself remained present.
  • Both affected plugins expose a static MCP App resource identity for their workspace/widget type rather than a unique resource identity per artifact or Security session. The host therefore receives multiple UI results with indistinguishable labels and does not appear to deduplicate or replace them.
  • Disabling a plugin while Desktop was already running did not unload the previously started per-task MCP runtime until the app was restarted.

No task IDs, local paths, repository details, or raw logs are included here.

Expected behavior

  1. Opening or reopening the same Security session should focus or update the existing workspace rather than create another tab.
  2. Artifact widgets should be keyed or deduplicated by artifact identity.
  3. Every persisted MCP App widget should have a close or dismiss action.
  4. If the original thread-scoped MCP resource is no longer available, the widget should fail recoverably instead of leaving an unusable tab.
  5. Agent retries or refresh attempts should not permanently accumulate duplicate UI results in task history.

This appears related to:

  • #32663, which documents persisted MCP App widgets being rehydrated into new renderer processes on macOS when a thread is reopened.
  • #33699, which requests a way to hide or collapse MCP tool widgets.

The cross-plugin macOS reproduction suggests the underlying issue is likely in the Desktop MCP App result lifecycle and restoration behavior, with repeated tool invocation acting as the trigger.

hellgate13 · 1 month ago

I can reproduce this on the current macOS build, and this run provides a narrower trigger and backend/UI distinction.

Environment

  • Codex Desktop: 26.715.72359 (bundle 5718)
  • App server: 0.145.0-alpha.30
  • macOS: 26.5.2 (25F84)
  • Architecture: arm64
  • Observed: 2026-07-23

Reproduction and diagnostic evidence

  1. Start a Codex Security repository scan in a Codex Desktop task.
  2. Let the agent invoke the Security MCP App tools repeatedly during the same scan, especially get_codex_security_scan_context, update_codex_security_scan_progress, and complete_codex_security_scan.
  3. Each UI-producing result can add another identically labeled Codex Security tab instead of updating/focusing the existing workspace.
  4. Closing the visible tab does not reliably clear the duplicates; a later context/status call can make another one appear.
  5. When further Security tool calls stop, the tab growth stops.

I inspected the local Security workbench after reproduction. It contained exactly two workspace/scan records—one intentionally failed Deep Scan and one completed Standard Scan—while the UI displayed four Codex Security tabs. This confirms that the repeated items are duplicated MCP App UI instances, not newly created backend scans.

Screen recording

https://github.com/user-attachments/assets/6567a2ec-1ba8-4dce-8d23-df62f3fccf2f

The 5.9-second recording shows four duplicate Security tabs and the attempted close interaction. It contains no source code or credentials.

Authorship disclosure: this comment was drafted and submitted by OpenAI Codex at the user's explicit request. The user personally reproduced the issue, supplied the recording, and authorized posting this evidence.