›_ Codex Issues
Codex Issues / #35866

[Windows][VS Code extension] Native modal disappears and leaves VS Code window disabled

Open 💬 0 comments Opened Jul 29, 2026 by pnikkosis

[Windows][VS Code extension] Native modal disappears and leaves one VS Code window permanently disabled

Summary

On Windows, a single VS Code workspace window can become permanently non-clickable after a dialog opened while using the Codex extension and the user switches away with Alt+Tab. The dialog is no longer visible or present in the Win32 window tree, but the affected top-level VS Code window remains Enabled = false.

This has occurred twice on the same machine, in two different VS Code workspace windows. Other VS Code windows in the same Code.exe process remained enabled and usable. Calling Win32 EnableWindow(hwnd, true) immediately restored the affected window without restarting VS Code or losing any work.

The exact defective state is confirmed. The initiating Codex action is still a probable cause rather than a proven one because the extension log does not record native dialog start/end events.

Environment

  • OS: Windows 11 Pro 25H2, build 26200.8875, x64
  • Session: Remote Desktop / Microsoft Remote Display Adapter
  • Active VS Code: 1.125.1, commit fcf604774b9f2674b473065736ee75077e256353
  • Electron used by that VS Code build: 42.2.0
  • A VS Code 1.130.0 update was already staged, but the long-lived main process had not restarted to apply it
  • VS Code main process start: 2026-07-16 11:33 local time
  • Codex extension currently installed: openai.chatgpt 26.721.41059 (win32-x64)
  • Previous installed build at the time window history began: 26.721.30844
  • Bundled Codex CLI: 0.146.0-alpha.3.1
  • codex doctor --json: overall status ok; config, auth, network, state databases, runtime and installation checks all passed
  • Multiple VS Code workspace windows share the same main Code.exe process

Occurrences

Occurrence A — 2026-07-24

  1. While using Codex in Workspace A, a Windows dialog appeared.
  2. The user switched away with Alt+Tab.
  3. On returning, the workspace still accepted some keyboard interaction but ignored mouse clicks.
  4. The dialog did not appear in Alt+Tab or Task Manager.
  5. An RDP disconnect/reconnect with two 1920x1080 monitors did not repair the window.
  6. Win32 inspection at 20:06 local time showed:
Class             Chrome_WidgetWin_1
Visible           true
Enabled           false
Owner             0x0
LastActivePopup    same HWND as the workspace
EnabledPopup       0x0
Directly owned top-level windows: none

All other visible VS Code workspace windows in the same process were Enabled = true.

Applying EnableWindow(target, true) changed the state from false to true and restored mouse input immediately.

Occurrence B — 2026-07-26

The same behavior occurred in a different workspace window in the same VS Code main process.

Win32 inspection at 00:51 local time showed:

Class             Chrome_WidgetWin_1
Visible           true
Enabled           false
Owner             0x0
LastActivePopup    same HWND as the workspace
PopupIsSelf        true

Again, EnableWindow(target, true) changed Enabled from false to true and restored the window immediately.

Occurrence C — 2026-07-28

At 22:16 local time, Workspace B became non-clickable for the second time. The diagnostic captured the same signature:

ProcessId         same long-lived Code.exe main process
Class             Chrome_WidgetWin_1
Visible           true
Enabled           false
Owner             0x0
LastActivePopup    same HWND as the workspace
PopupIsSelf        true
EnabledPopup       0x0

A separate previously affected workspace was simultaneously present as Visible = true, Enabled = false, also with LastActivePopup = self and EnabledPopup = 0. Other workspace windows in the same process remained enabled.

Only Workspace B was repaired. EnableWindow(target, true) changed it from false to true and a second diagnostic pass confirmed the repaired state. The other disabled workspace was intentionally left untouched.

At this third occurrence:

  • the active VS Code process was still version 1.125.1;
  • the same main process had been running continuously since 2026-07-16;
  • VS Code 1.130.0 was still staged but unapplied;
  • the installed Codex extension was still 26.721.41059.

This recurrence strengthens the orphaned-modal diagnosis and suggests that a long-lived multi-window VS Code process with pending application updates may increase exposure to the lifecycle defect. It still does not prove that the Codex file picker is the initiating dialog.

Expected behavior

When a Codex-triggered dialog is closed, cancelled, destroyed, loses its webview requester, or is interrupted by a window/extension-host reload, its owner VS Code window must always be re-enabled.

Actual behavior

The modal disappears, but its owner workspace remains disabled at the Win32 level. There is no remaining visible or hidden owned popup that the user can activate or close. Reloading the renderer/extension host and reconnecting the RDP session did not clear the disabled flag.

Relevant Codex extension implementation

Inspection of the installed extension bundle found one native file-dialog path in each of the four locally retained Codex builds:

async pickFilesFromDialog({ allowMultiple, imagesOnly = false, title }) {
  const result = await vscode.window.showOpenDialog({
    canSelectFiles: true,
    canSelectFolders: false,
    canSelectMany: allowMultiple,
    // optional image filters
    title
  });
  // map selected URIs
}

The showOpenDialog implementation is identical in 26.721.30844 and 26.721.41059. Each bundle contains:

  • one showOpenDialog call;
  • handlers for pick-file and pick-files;
  • no showSaveDialog, showInputBox, or showQuickPick call;
  • one unrelated explicit modal information message for an experimental LSP command.

If the dialog observed by the user was the Windows file picker opened by the attachment flow, this is the most likely trigger. The current Codex logs do not record pick-file / pick-files request lifecycle, so this correlation cannot yet be proven from logs alone.

Timeline correlations

  • Both affected workspace windows had an extension-host/window reload around the incident. The reload did not normalize the top-level Win32 enabled state.
  • The first disabled state survived a full RDP disconnect/reconnect.
  • The second occurrence did not coincide with an RDP reconnect, so RDP alone does not explain the defect.
  • Codex logs contain repeated ResizeObserver loop completed with undelivered notifications and IPC warnings, but those messages do not explain or manipulate the Win32 Enabled state and are likely incidental UI noise.
  • No Get-Credential, Read-Host, or other interactive shell credential prompt was executed around the second occurrence.
  • Windows Application logs contain no Code.exe crash or Application Hang event at either occurrence.

Probable failure chain

  1. The Codex webview requests pick-file or pick-files.
  2. The extension calls vscode.window.showOpenDialog, which opens a native modal owned by one VS Code workspace and disables that owner.
  3. Alt+Tab plus cancellation, webview disposal, extension-host/window reload, or another lifecycle race destroys or orphans the dialog.
  4. The owner window is not re-enabled.
  5. VS Code remains otherwise healthy, so only the affected workspace rejects mouse input.

Confidence:

  • High: the final broken state and recovery mechanism.
  • Medium: a native modal lifecycle race.
  • Medium-low until the dialog type is confirmed: the Codex attachment/file-picker path as the initiating action.

Suggested reproduction matrix

Use a disposable VS Code window on Windows:

  1. Open several VS Code workspace windows in one long-lived process.
  2. Open the Codex panel.
  3. Trigger the attachment file picker.
  4. While the native picker is open, try these variants:
  • Alt+Tab to another VS Code window, then cancel the picker;
  • Alt+Tab and reload the originating VS Code window;
  • close/reopen the Codex panel while the picker is pending;
  • restart the extension host while the picker is pending;
  • disconnect/reconnect an RDP session while the picker is pending;
  • repeat after an extension update has been installed but before the main VS Code process is restarted.
  1. Inspect the originating top-level HWND with IsWindowEnabled, GetLastActivePopup, GetWindow(GW_ENABLEDPOPUP), and owner enumeration.

Failure signature:

Visible=true
Enabled=false
LastActivePopup=self
EnabledPopup=0
No owned top-level popup

Suggested fixes and diagnostics

  1. Add structured, non-sensitive logs for pick-file / pick-files: request start, native dialog open, resolve/cancel/error, requester disposal, and elapsed time with a correlation ID.
  2. Serialize file-picker requests and reject duplicate concurrent picker requests.
  3. Test cancellation while the webview, extension host, or workspace window is being reloaded/disposed.
  4. Verify whether this is a VS Code/Electron showOpenDialog defect and, if so, forward a minimal reproducer upstream with the exact Win32 failure signature.
  5. Consider a watchdog or visible recovery path if the native dialog request ends but the owning window remains disabled on Windows.
  6. Ensure feedback logs include extension version, active VS Code/Electron version, window lifecycle events, and file-picker lifecycle events.

Privacy

Workspace names, repository paths, user prompts, command output, credentials, network addresses, and raw Codex logs are intentionally omitted. Raw logs are available locally and should only be included after privacy review.

Feedback command discrepancy

The current Codex IDE documentation lists /feedback as an IDE slash command. However, the installed extension build openai.chatgpt 26.721.41059 does not recognize /feedback, and its JavaScript bundle contains no /feedback slash-command literal.

The installed bundle contains a shared application-command definition with ID feedback, and package.json exposes the VS Code command chatgpt.openCommandMenu as Codex: Open Codex Command Menu. Nevertheless, Feedback is not shown in that command menu in this VS Code build. The shared command definition is therefore not evidence that the feature is wired into the IDE surface.

Neither documented in-product feedback route is usable in this environment. The official troubleshooting documentation also provides a direct Codex GitHub bug-report form, which is the viable reporting route for this incident:

https://github.com/openai/codex/issues/new?template=2-bug-report.yml

This documentation/runtime mismatch should be included in the report.

Existing issue search

As of 2026-07-26, searches in the public openai/codex issue tracker for showOpenDialog, invisible dialog, file picker plus Windows extension, and the Win32 disabled-window signature did not find an exact match. There are other Windows extension responsiveness issues, but their symptoms do not establish this orphaned-modal state.

View original on GitHub ↗