[Windows][WSL] Integrated terminal auto-closes when Git availability probe fails

Additional source-level fix proposal and local validation:

• This terminal symptom is downstream of #35119, but the terminal should not be destroyed by an optional Git-enrichment failure.
• In WSL mode, keep the Git probe cwd host-native and absolute:

• use / (or another valid absolute Linux path) for the availability probe;
• translate codexHome back to Linux form before POSIX parsing; or
• omit --cd when no valid cwd is available.

• Harden the shared WSL command builder so an empty cwd does not become wsl.exe --cd .. On the affected setup:

• --cd . → Wsl/E_INVALIDARG
• --cd / → unchanged Git probe succeeds

• Treat terminal Git/worktree environment lookup as optional. Conceptually:

const gitEnvironment = await getWorktreeEnvironment(...).catch(() => null);
// Continue creating the PTY even when gitEnvironment is null.

• Local A/B validation used an isolated copy of the same production build:

• changing only the terminal enrichment failure handling made the WSL terminal remain open;
• changing the three duplicated Git availability checks to use an absolute WSL cwd removed the reproduced WSL argument error.

• The local binary modification was diagnostic validation, not a recommended end-user distribution method. The production fix belongs in the Git probe, shared WSL spawn builder, and terminal error boundary.

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

• #37821
• #37771
• #37104

Powered by Codex Action

Closing as a duplicate of #37104. This issue remains as the sanitized exact trace for build 26.803.81509; the underlying Git-probe regression is #35119, with related terminal reports #37821 and #37771.

Reopened. The previous ‘not planned’ closure was performed by the reporter while consolidating potential duplicates; it was not a maintainer disposition. This report remains distinct enough to track because it provides an exact, reproducible two-layer failure on build 26.803.81509: the WSL Git availability probe generates the invalid \wsl.exe --cd .\ invocation, and that optional Git-enrichment rejection is then treated as fatal by terminal creation before \
ode-pty.spawn\. Related terminal reports are #37104, #37821, and #37771; the underlying Git regression is #35119.

Additional reproduction on Windows 11, using the same Microsoft Store package:

Environment

• Codex Microsoft Store package: 26.803.10989.0
• Windows 11 24H2, build 26100 (Windows PowerShell 5.1.26100.8875)
• WSL 2.9.4.0, Ubuntu, WSL2, kernel 6.18.35.2
• Agent execution environment: WSL
• Integrated terminal selection: PowerShell (not WSL)
• Project stored on C: and accessed by the WSL agent through /mnt/c/...

A/B result

• Before switching the agent from Windows native to WSL, the integrated terminal opened normally.
• After switching only the agent to WSL and restarting the app, the terminal drawer flashes briefly and immediately closes.
• Changing the independently configured integrated terminal from WSL to PowerShell and restarting does not help.
• Repairing the Store app and restarting does not help. Microsoft Store reports no newer package version.

This shows that the failure is tied to the WSL agent initialization path and occurs before the selected terminal shell is spawned. Selecting PowerShell is not a workaround while the agent remains in WSL mode.

Checks and logs

• PowerShell starts normally outside the Codex terminal, and the Windows project path exists.
• No Application Error, Windows Error Reporting, or AppHang event is recorded when the drawer closes.
• The bundled node-pty / ConPTY native files are present.
• App startup repeatedly logs:

bundled_executable_relocation_failed ... sourcePath=...\\app\\resources\\codex-resources\\bwrap ... errorCode=ENOENT

• It then logs:

Failed to apply worktree shell environment config ... Git is unavailable

• No terminal, ConPTY, PowerShell, or PTY-spawn event appears when the drawer closes.

This is consistent with the failure chain described in this issue and adds an A/B case showing that the documented independent terminal selection cannot bypass the WSL-agent-side failure.

I can reproduce this on a newer Microsoft Store build, so the issue does not appear to be fixed yet.

My setup is:

• Codex App 26.810.7004.0
• Windows 11 x64, build 26200
• WSL 2.7.11.0
• Ubuntu 24.04 on WSL2
• Kernel 6.18.33.2-microsoft-standard-WSL2
• Codex configured to run in WSL

When I click the integrated terminal button, the panel appears for a moment and immediately closes. I tried selecting both WSL and PowerShell as the integrated terminal, but the result is the same.

While monitoring the processes started by Codex, I saw it run the equivalent of:

wsl.exe -d Ubuntu-24.04 --cd . -- /usr/bin/bash -lc "<Git availability probe>"

This exits before Git or the selected terminal shell starts, with:

Wsl/E_INVALIDARG

I also tested the WSL commands directly from PowerShell to rule out a broken WSL installation:

• wsl -d Ubuntu-24.04 --exec /bin/bash --noprofile --norc works.
• Using --cd . fails with Wsl/E_INVALIDARG.
• Using --cd ~, --cd /home/<user>, an absolute /mnt/c/... path, or an absolute Windows path works.
• git --version works normally in both Windows and WSL.
• Updating and restarting WSL, restarting Windows, and changing the integrated terminal shell do not make a difference.

It looks like this fails during the WSL Git availability/environment check, before the PTY or the chosen terminal shell is started. That would also explain why selecting PowerShell does not help.

The WSL command builder should avoid passing the relative path . to wsl.exe --cd. It could translate the path to an absolute Linux path or omit --cd when there is no valid working directory. A failure in this optional Git/worktree environment lookup also should not prevent the terminal itself from opening.

Request for maintainer ownership and a shipped fix

This remains unresolved as a product issue and needs an official response, an owner, and a fixed Microsoft Store build.

This is not a cosmetic terminal problem and it is not a broken local Git or WSL installation. It breaks two core Desktop workflows for Windows users who select WSL:

1. Git integration: valid repositories are classified as non-Git, so branch state, change tracking, repository actions, and native worktree workflows become unavailable.
2. Integrated terminal: an optional Git/worktree-enrichment failure is treated as fatal, so the terminal tab is destroyed before a PTY or the selected shell is started.

The scope is potentially broad because the failure is in the shared Windows/WSL adapter and Git worker, not in a particular repository. Multiple users have reproduced it across Windows 10 and 11, multiple WSL releases and distributions, and multiple Codex Desktop builds. Git and WSL continue to work outside the app. Repairing or reinstalling the Store package does not correct shipped application logic.

OpenAI's own documentation describes the integrated terminal as project/worktree-scoped and specifically lists Git operations such as git status and git pull --rebase as intended uses: https://learn.chatgpt.com/docs/integrated-terminal. When the same first-party WSL integration prevents both repository detection and terminal creation, users cannot reasonably repair that from settings. The fix belongs in the shipped application.

Given that this is a first-party desktop integration, the reasonable expectation is an official patched build and a clear release confirmation—not requiring customers to inspect or modify packaged JavaScript. Please assign an owner, acknowledge whether the reproduction is confirmed, and identify the first Store package containing the fix.

Root cause — general explanation

The Windows Desktop app crosses three path/process domains: Windows paths, WSL/Linux paths, and wsl.exe command-line arguments. The availability probe constructs a WSL process using a working directory derived through the wrong path semantics. That makes a healthy WSL Git installation appear unavailable.

The terminal then performs Git/worktree environment enrichment before creating its PTY. Although that enrichment is optional metadata, its rejection is allowed to escape. The renderer consequently treats terminal creation as failed and removes the tab. One WSL-boundary bug therefore disables Git integration and is amplified into a total terminal failure.

Root cause — detailed failure chain

The original reproducible path is:

1. In WSL mode, codexHome() can be represented on the Windows side as a UNC path such as \\wsl.localhost\<distro>\home\<user>\.codex.
2. The Git availability code simultaneously uses the POSIX platformPath() implementation.
3. Parsing that Windows UNC value with POSIX path rules does not produce a valid absolute Linux root.
4. The WSL spawn layer falls back to a relative working directory and constructs the equivalent of:

``text
wsl.exe -d <distro> --cd . -- /usr/bin/bash -lc <git-probe>
``

1. wsl.exe --cd . fails with Wsl/E_INVALIDARG before Bash or Git starts.
2. The Git worker records the probe as unavailable, so a valid WSL repository is reported as non-Git and branch/worktree features disappear.
3. Terminal creation calls gitManager.getWorktreeRepository(...) to enrich the shell environment before PTY creation.
4. The Git failure rejects that lookup. The terminal callback does not isolate the optional failure, so the rejection reaches terminal-session creation.
5. The renderer cleans up the failed session/tab. node-pty.spawn and the user's selected shell are never reached.

There is also evidence in #35119 of a second WSL command-construction defect on newer builds: even with an absolute --cd /, using bare -- can allow an earlier/default shell to expand the nested probe before the intended /usr/bin/bash -lc receives it. On affected systems, variables such as $git arrive empty and the probe still fails. The WSL builder should use the documented --exec/-e form and preserve the intended argv boundary.

On the currently installed Store package OpenAI.Codex_26.818.5229.0_x64, an isolated copy of the original runtime still contained the unguarded terminal worktree lookup. A guarded, byte-length-preserving local A/B patch again made the terminal survive the Git lookup failure. This validates the error-boundary fix, but binary patching is only diagnostic evidence and is not an acceptable distribution mechanism.

What a clean production fix should look like

This needs defense in depth because Git capability detection and terminal availability are separate concerns.

1. Make the Git probe WSL-native

Choose the working directory from the execution host, not by parsing a Windows UNC string with POSIX rules:

const probeCwd = host.kind === "wsl"
  ? "/" // or a translated absolute Linux codexHome
  : platformPath.parse(codexHome).root || platformPath.sep;

Before adding --cd, require a host-valid absolute path. Never substitute . for a missing WSL cwd; either use a known valid absolute Linux directory or omit --cd.

2. Preserve the WSL argv boundary

Invoke the intended executable explicitly:

const args = [
  "-d", distro,
  "--cd", absoluteLinuxCwd,
  "--exec", "/usr/bin/bash", "-lc", probeCommand,
];

Do not use a bare -- path that permits an unintended default-shell expansion of the nested Git probe. Arguments should be passed as an argv array, not reconstructed as another command string.

3. Never make optional Git metadata a prerequisite for the terminal

The local diagnostic patch used the minified equivalent of this behavior:

let repository = null;
try {
  repository = await gitManager.getWorktreeRepository(cwd, appServerClient);
} catch (error) {
  logger.warn("Git/worktree environment enrichment failed; starting terminal without it", { error });
}

const shellEnvironment = repository
  ? await getWorktreeShellEnvironment(repository).catch(error => {
      logger.warn("Worktree shell environment lookup failed; using base environment", { error });
      return null;
    })
  : null;

return createPty({
  ...terminalOptions,
  env: mergeEnvironment(baseEnvironment, shellEnvironment),
});

Git enrichment may improve the terminal environment, but it must not determine whether a terminal exists. A visible warning is preferable to silently destroying the panel.

4. Add regression coverage at the actual boundaries

At minimum, automated coverage should include:

• Windows host + WSL execution with codexHome represented as a \\wsl.localhost\... UNC path.
• WSL distributions whose default shell is Bash and Zsh.
• Probe commands containing nested quotes and shell variables, verifying that the target shell receives them unchanged.
• An assertion that WSL receives an absolute --cd and an explicit --exec executable.
• A healthy WSL repository being detected as Git, with branch, status, and worktree operations available.
• Forced Git-probe and getWorktreeRepository failures while asserting that PTY creation still occurs and the terminal remains visible.
• Both WSL and PowerShell integrated-terminal selections while the agent environment is WSL.

Requested resolution

Please provide:

1. Maintainer confirmation of the reproduced failure chain.
2. An assigned owner or linked internal/public tracking reference.
3. A production fix covering both WSL Git detection and terminal failure isolation.
4. The Microsoft Store package/build number containing that fix.
5. Confirmation that Git status, branch detection, worktree creation, and integrated-terminal startup were tested on Windows 10/11 with WSL2.

Until that happens, this issue should remain open. The local wrapper proves that the two immediate failure points can be corrected, but users should not be expected to maintain a patched copy of a signed Store application's runtime to restore documented core functionality.