Windows Codex app creates duplicate unclosable Security workspaces
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
- In a local Git project with a staged diff, open a Codex Security workspace for the staged changes.
- Observe that multiple duplicate Security workspace tabs may open.
- 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.
2 Comments
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
26.707.91948(build5440)0.144.5Symptoms
Sanitized diagnostic evidence
render_artifactresults. On task reopen, both were mounted as separateDataanalyticswidgettabs with the same generic label.open_codex_security_workspacecalls: 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.mcpServer/resource/readfailing for a persisted widget withthread not found. A later read could succeed after the task runtime was restored, while the stale tab itself remained present.No task IDs, local paths, repository details, or raw logs are included here.
Expected behavior
This appears related to:
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.
I can reproduce this on the current macOS build, and this run provides a narrower trigger and backend/UI distinction.
Environment
26.715.72359(bundle5718)0.145.0-alpha.3026.5.2(25F84)arm64Reproduction and diagnostic evidence
get_codex_security_scan_context,update_codex_security_scan_progress, andcomplete_codex_security_scan.Codex Securitytab instead of updating/focusing the existing workspace.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 Securitytabs. 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.