Codex Desktop Windows+WSL creates in-app browser WebView despite wsl-disabled and spams git-repo-watcher EISDIR

What version of the Codex App are you using?

Codex Desktop for Windows.

Release shown in logs:

26.707.31428

Windows package path observed in logs:

OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0

What platform is your computer?

Windows with WSL2 Ubuntu. Codex Desktop is using a WSL-backed project/workspace.

Representative sanitized paths:

WSL project path: /home/<wsl-user>/projects/<repo>
Windows UNC path observed in logs: \\wsl$\Ubuntu\home\<wsl-user>\projects\<repo>
Dev server URL: http://localhost:5173

What issue are you seeing?

Codex Desktop on Windows appears to mishandle the in-app browser and Git watcher when the active project lives inside WSL.

The app previously exited unexpectedly shortly after the in-app browser WebView was created for a localhost dev server. After restart, logs still show the in-app browser availability resolving to wsl-disabled, while the UI/session lifecycle continues to bind in-app browser routes and create WebViews. At the same time, the Git repo watcher repeatedly fails with EISDIR against \\wsl$\Ubuntu\... paths.

This looks like a Windows Desktop + WSL compatibility issue, not a project-code issue.

What steps can reproduce the bug?

1. Use Codex Desktop on Windows with a project stored in WSL, e.g. /home/<wsl-user>/projects/<repo>.
2. Run a frontend dev server inside WSL, e.g. http://localhost:5173.
3. Open the Codex in-app browser / browser sidebar for that localhost URL.
4. Observe Desktop logs around Browser Use / IAB lifecycle and Git repo watcher.
5. In my repro, Codex Desktop exited unexpectedly shortly after the in-app browser WebView was created/attached.
6. After restart, the same environment continued to log reason=wsl-disabled while still emitting IAB_LIFECYCLE route/binding events.

Expected behavior

If in-app browser support is disabled for WSL:

browser_use_availability_resolved available=false reason=wsl-disabled

Codex Desktop should not proceed to create/bind in-app browser WebViews for that WSL task in a way that can destabilize or crash the app.

The Git repo watcher should either correctly watch WSL project Git paths or gracefully disable/degrade watching without repeatedly logging EISDIR.

Actual behavior

The logs show in-app browser availability explicitly disabled for WSL:

2026-07-10T14:37:43.297Z info [electron-message-handler] browser_use_availability_resolved available=false browserPane=true platform=Windows reason=wsl-disabled release=26.707.31428

Despite that, in-app browser lifecycle/session routing still occurs:

2026-07-10T14:37:43.297Z info [electron-message-handler] IAB_LIFECYCLE received browser sidebar owner sync ...
2026-07-10T14:37:43.300Z info [browser-session-registry] IAB_LIFECYCLE captured session route ...
2026-07-10T14:47:31.442Z info [electron-message-handler] IAB_LIFECYCLE renderer created browser sidebar webview ... initialUrl=http://localhost:5173/

The Git watcher repeatedly fails on WSL paths:

warning [git-repo-watcher] Failed to watch git path errorCode=EISDIR errorMessage="EISDIR: illegal operation on a directory, watch '\\\\wsl$\\Ubuntu\\home\\<wsl-user>\\projects\\<repo>\\.git'"
path=/home/<wsl-user>/projects/<repo>/.git

There is also evidence of Windows/WSL path conversion problems in the bundled plugin reconciliation path:

errorMessage="ENOENT: no such file or directory, access 'C:\\mnt\\c\\Users\\<windows-user>\\.codex\\plugins\\cache\\openai-bundled\\chrome\\26.707.31428'"
marketplacePath=/mnt/c/Users/<windows-user>/.codex/.tmp/bundled-marketplaces/openai-bundled/.agents/plugins/marketplace.json
platformFamily=unix
pluginName=chrome

Mitigations already tried

Disabled the external Chrome plugin in Codex config while leaving the in-app browser plugin enabled:

[plugins."chrome@openai-bundled"]
enabled = false

[plugins."browser@openai-bundled"]
enabled = true

Verified codex plugin list reports:

chrome@openai-bundled installed, disabled 26.707.31428

Disabled/removed the external Chrome extension from the user's Chrome profile. Later logs changed from:

isExtensionInstalled=true
chromeExtensionSyncAction=keep_installed

to:

isExtensionInstalled=false
chromeExtensionSyncAction=keep_user_managed

This appears to resolve the external Chrome-extension side path, but the WSL in-app browser lifecycle and Git watcher issues remain.

User impact

The user cannot safely use Codex Desktop's in-app browser for a WSL-based frontend dev workflow. The current workaround is to run the dev server in WSL and open localhost in an external Chrome/Edge browser instead of the Codex in-app browser.

Related issues

This seems related to, but not an exact duplicate of:

• #30565: Windows App WSL file links and built-in browser preview do not work for WSL projects.
• #30435: WSL agent bad cwd and Chrome/Computer Use unavailable.
• #29639: Browser Use Node REPL fails in Windows Desktop app with WSL workspace due to unmapped sandboxCwd.
• #25301: Computer Use unavailable in Windows Desktop when app-server runs in WSL (reason=wsl-disabled).
• #24268: Windows+WSL resolves bundled plugin cache as invalid C:\mnt\c path.
• #17991: Windows desktop Summary tab shows WSL Git watcher path issues, though that issue reports ENOENT rather than EISDIR.

This issue is specifically about the combination of:

1. browser_use_availability_resolved ... reason=wsl-disabled,
2. continued IAB_LIFECYCLE route/WebView creation for the WSL task,
3. repeated git-repo-watcher EISDIR on \\wsl$\Ubuntu\... Git paths,
4. an earlier unexpected Desktop exit immediately after opening the in-app browser for a WSL-hosted localhost page.

Requested investigation

Please investigate:

1. Why IAB_LIFECYCLE proceeds after browser_use_availability_resolved available=false reason=wsl-disabled.
2. Whether the Windows Desktop Git watcher is incorrectly using Windows fs.watch semantics on WSL UNC directories.
3. Whether the C:\mnt\c\... path conversion during bundled plugin reconciliation is related to the same Windows/WSL path handling issue.
4. Whether Codex Desktop should explicitly suppress or disable the in-app browser button/pane for WSL tasks until this path is supported.

Privacy note

Local user names, exact project names, and thread IDs have been redacted. The snippets above contain only sanitized method names, feature state, package family/version, and error strings needed to diagnose the product behavior.