Skip to content

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

Open
Open
Codex Desktop Windows+WSL creates in-app browser WebView despite wsl-disabled and spams git-repo-watcher EISDIR#32183
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@Stellogic
Stellogic
opened on Jul 10, 2026

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:

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    browser
    on Jul 10, 2026

  2. github-actions commented on Jul 10, 2026

    @github-actions
    github-actionsbot
    on Jul 10, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. tompw89 commented on Jul 11, 2026

    @tompw89
    tompw89
    on Jul 11, 2026 – with ChatGPT Codex Connector

    Adding a fresh reproduction after a complete Codex Desktop restart on the same release family.

    Environment

    • Microsoft Store/MSIX package: OpenAI.Codex_26.707.3748.0_x64
    • Desktop/browser release in logs: 26.707.31428
    • Windows 11 with a WSL2 Ubuntu agent
    • Project stored on the native WSL filesystem: /home/<wsl-user>/projects/<repo>
    • Codex CLI in the WSL session: 0.144.1
    • WSL-specific Codex home; generated Node REPL env uses CODEX_HOME=C:\Users\<windows-user>\.codex_wsl

    Fresh restart result

    Settings > Browser shows:

    In-app browser plugin unavailable

    The fresh Desktop log resolves availability as:

    browser_use_availability_resolved available=false browserPane=true platform=Windows reason=wsl-disabled release=26.707.31428

    This is despite all of the following:

    • browser_use=true
    • in_app_browser=true
    • generated node_repl MCP present and enabled
    • selected Windows node_repl.exe and Node v24.14.0
    • BROWSER_USE_AVAILABLE_BACKENDS="chrome"

    A no-op node_repl/js call still fails before JavaScript executes:

    Mcp error: -32602: js: codex/sandbox-state-meta:
sandboxCwd is not a local file URI: file:///home/<wsl-user>/projects/<repo>

    The same Codex home also previously logged both adjacent WSL path failures described here:

    C:\mnt\c\Users\<windows-user>\.codex_wsl\plugins\cache\...
EISDIR ... watch '\\wsl$\Ubuntu\home\<wsl-user>\projects\<repo>\...'

    Important isolation

    Workspace Dependencies were repaired separately. Settings now reports primary runtime 26.709.11516; bundled Node and Python resolve and execute successfully. The missing extensionless Linux codex-code-mode-host was restored from the signed installed Desktop package and hash-verified. After that repair and a full Desktop restart, the Browser result remained reason=wsl-disabled and the Node REPL call retained the same sandboxCwd failure.

    This therefore does not appear to be caused by an absent primary workspace runtime. The remaining failure is the WSL Browser eligibility gate plus the Windows/WSL sandboxCwd bridge.

  4. aussiDavid commented on Jul 15, 2026

    @aussiDavid
    aussiDavid
    on Jul 15, 2026

    I’m seeing what looks like the same underlying issue on a newer Codex Desktop build.

    Environment:

    • Codex Desktop / ChatGPT desktop app package observed: OpenAI.Codex_26.707.9981.0_x64
    • Windows build observed: 10.0.26200
    • WSL2 repo path shape: \\wsl.localhost\<WSL_DISTRO>\home\<WSL_USER>\<REPO_NAME>
    • Git repository uses worktrees

    Observed behavior:

    • The desktop app restarted twice within about 15 minutes.
    • Windows AppModel-Runtime/Admin showed the Codex AppX container being destroyed and then recreated a few seconds later.
    • I did not find a corresponding Windows Error Reporting crash dump or direct Application Error event for ChatGPT.exe.
    • Codex logs were flooded with thousands of git-repo-watcher warnings before/around the restarts.

    Representative redacted log line:

    warning [git-repo-watcher] Failed to watch git path
errorCode=EISDIR
errorMessage="EISDIR: illegal operation on a directory, watch '\\\\wsl.localhost\\<WSL_DISTRO>\\home\\<WSL_USER>\\<REPO_NAME>\\.git'"
path=\\wsl.localhost\<WSL_DISTRO>\home\<WSL_USER>\<REPO_NAME>\.git\HEAD

    Other failing paths included:

    .git\index
.git\FETCH_HEAD
.git\packed-refs
.git\refs
.git\refs\heads
.git\info
.git\config
.git\config.worktree
.git\codex-synced-branch.json

    One fresh app session generated thousands of these EISDIR watcher errors within minutes.

    I have not confirmed the in-app browser/WebView part of this issue in my case. The strongest signal I found is the git-repo-watcher loop on WSL UNC paths, and it correlates with repeated desktop app restarts.

  5. gilmarvitor commented on Jul 16, 2026

    @gilmarvitor
    gilmarvitor
    on Jul 16, 2026

    I'm seeing the same git-repo-watcher failure pattern reported here, but inside a valid WSL Git repository (not a non-repository workspace). In my environment, the watcher repeatedly fails with EISDIR trying to watch \\wsl$\Ubuntu\home\<wsl-user>\workspace\<workspace>\.git, very similar to what @aussiDavid reported in this issue.

    Environment:

    • Codex Desktop/MSIX: OpenAI.Codex 26.707.9981.0
    • Runtime reported in logs: 26.707.72221
    • Codex CLI: 0.144.2
    • Windows 11, build 10.0.26200.8875, x64
    • WSL: 2.7.10, Ubuntu 24.04, WSL kernel 6.18.33.2
    • Agent configured to run in WSL2, workspace on ext4 under /home

    Unlike the non-Git-repository directory scenario (which I already reported separately in issue #32695, related to git-init-watcher), this case occurs inside a valid, active WSL Git repository, and the error rate is much higher.

    Measurement observed in my session: approximately 11.9 EISDIR warnings per second, which projects to roughly 41,631 failures per hour, producing around 44 MiB of logs from these repeated warnings alone.

    This suggests the issue is not just cosmetic: the logging I/O volume and the indefinite retry of watching a \\wsl$\... UNC path seem to indicate that the Windows-side watcher is using fs.watch semantics incompatible with this type of path, without any backoff or disabling after permanent failures.

    I did not try to work around this by moving the project to Windows or switching the agent to run natively on Windows, since that would not address the underlying watcher issue.

    This could potentially be addressed with one of the approaches already suggested in this and related issues: running the watcher in the same environment as the filesystem (inside WSL), using a WSL-compatible backend, or implementing backoff/disabling of the watcher after detecting a permanent EISDIR-type failure for this kind of path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions