Windows Codex app creates duplicate unclosable Security workspaces #32180

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   safety-checkIssues related to safety and abuse checksIssues related to safety and abuse checks

   on Jul 10, 2026
2. etraut-openai

   added

   aardvark

   and removed

   safety-checkIssues related to safety and abuse checksIssues related to safety and abuse checks

   on Jul 10, 2026
3. mdotk commented on Jul 17, 2026

   

   mdotk

   on Jul 17, 2026

   More actions

   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:

   • MCP App webviews leak Codex Renderer processes on thread reopen (203 widgets → +209/+216 renderers) #32663, which documents persisted MCP App widgets being rehydrated into new renderer processes on macOS when a thread is reopened.
   • Allow hiding MCP tool widgets in Codex App #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.
4. hellgate13 commented on Jul 23, 2026

   

   hellgate13

   on Jul 23, 2026

   More actions

   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

   2026-07-23.6.07.42.mov

   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.