[Windows][WSL] 26.721.3404 marks valid WSL repositories as non-Git and reports "Git is unavailable"

Facing the same issue here. Git repos in windows filesystem do get recognized but the ones from WSL does not.

Same. I'd like to add that this isn't repo specific. If I'm using ChatGPT Desktop, go into Settings->Worktrees, it says "No worktrees yet"(although I had plenty before the update). It says "Worktrees created by ChatGPT will appear here".

If I press the refresh button, it will say "Fetching worktree details.." then turn to "Unable to load worktrees", and "Git is unavailable" in the card. This absolutely broke on this build, as everything was fine just before I did the update.

I've uninstalled it, reinstalled it, wiped out my .codex folders to start from complete scratch, and the issue remains on a completely fresh install.

I had Codex self-reflect on ChatGPT Desktop and it was able to make a copy and self-repair. I'm not posting their source here, but can say it's basically trying to parse a Windows-type path within the WSL platform and that's blowing up a precheck probe. There is no workaround. I sent the details to their support, but I don't know if it will get here. If someone from OpenAI wants the details please reach out to me.

experiencing the same thing feedback id: 019f8fb2-6d1b-7511-bbc7-884242272cd3

Confirming this regression on the current Windows package 26.721.4979.0 (internal app release 26.721.41059) with Windows 11 + WSL2 (Ubuntu).

The problem affects multiple repositories stored on the WSL ext4 filesystem. Git remains healthy inside WSL:

• git --version succeeds (2.43.0)
• git rev-parse --show-toplevel returns the expected repository root
• git status succeeds
• repository integrity checks succeed

Codex Desktop still does not show the active branch or offer native worktree creation. Fully quitting the app, normalizing the persisted project roots to Linux POSIX paths, rebuilding the local project registry, and restarting did not change the result.

The current Desktop logs contain the same signature reported here:

Git is unavailable
worker_rpc_response_error method=turn-diff-capture-start workerId=git

They also show recommended-skills Git operations failing with git fetch failed: Git is unavailable.

The CLI continues to recognize and operate on the same repositories correctly. This appears to confirm that the regression persists in 26.721.4979.0 and is isolated to the Windows Desktop Git worker / WSL handoff rather than repository state.

Confirming this regression on the Microsoft Store package 26.721.4979.0 (internal app release 26.721.41059, bundled CLI/app-server 0.146.0-alpha.3.1) with Windows 11 + WSL2.

I isolated the failure to the Desktop Git worker's preliminary Git-availability check, rather than repository detection or Git itself. In WSL mode that check obtains codexHome, platformFamily, and platformPath, then probes git --version with a working directory derived from those values. Static inspection indicates a Windows/WSL path mismatch in this precheck. When the probe fails, the worker short-circuits later operations as Git is unavailable.

For an A/B validation, I tested an isolated copy of the same app bundle where only the three duplicated availability-check call sites were bypassed. I did not change git rev-parse, status, diff, branch, repository, or worktree logic.

Results after bypassing only that precheck:

• WSL Git remains 2.43.0.
• Real repositories on both /mnt/c/... and the WSL ext4 filesystem are returned as isGitRepository:true.
• Non-Git directories remain isGitRepository:false.
• Branch/worktree/code-review UI is restored.
• The fresh Desktop log no longer contains Git is unavailable.

This strongly suggests the official fix should normalize/translate the probe cwd before spawning Git, or make the availability probe independent of a codexHome-derived cwd. The unconditional bypass was used only as local A/B validation; it is not a suggested production implementation.

It's time for you to get serious about fixing problems with WSL. For both TUI and App. It has been impossible to use for months.

@etraut-openai @jmalmo

I'm eagerly awaiting a resolution to this issue, but it's disappointing that OpenAI doesn't seem very interested in Windows support.

I've now given up and am using the Codex App via WSLg (but it's unstable).

Confirming the same regression on Windows ARM64 + WSL2 Ubuntu ARM64, so this is not limited to the x64 packages already reported here.

Environment

• Microsoft Store package: OpenAI.Codex_26.721.11231.0_arm64
• Bundled app-server: 0.146.0-alpha.3.1
• Windows 11 ARM64
• WSL2 Ubuntu, Linux architecture aarch64
• Repository stored on WSL ext4 under /home/<user>/code/<repo>
• Project selected through the documented \\wsl$\Ubuntu\home\... Windows path, with the Codex agent environment set to WSL

Split detection result

Git and the WSL-side Codex agent recognize the repository correctly:

• git --version succeeds (2.34.1)
• git rev-parse --show-toplevel returns the expected Linux path
• git status succeeds
• git worktree list --porcelain succeeds
• the Codex thread metadata contains the correct Git SHA, branch, and origin URL

However, the Desktop project API returns the same project as:

isGitRepository: false

Consequently, the review panel and native worktree controls are unavailable.

The Desktop startup log includes:

git fetch failed: Git is unavailable
bundled_executable_relocation_failed ... bwrap ... ENOENT

Historical logs from the same installation also show the Windows-side git-repo-watcher receiving EISDIR while watching \\wsl$\Ubuntu\...\.git directories.

The path itself is translated successfully: the running agent's cwd is the correct /home/<user>/code/<repo> Linux path. This appears to be the same Desktop Git-worker availability/precheck failure described above, rather than a bad project path or repository state.

One potentially relevant ARM64-specific detail: static inspection of the installed runtime manifest lists Windows/Linux x86_64 primary-runtime artifacts but no Windows/Linux ARM64 artifact. Since the externally visible failure matches the x64 reports exactly, that may be incidental, but ARM64 is definitely affected as well.

This bug is still present in the latest version, 26.727.40816.

For a temporary workaround, here is a prompt you can give to GPT-5.6-Sol (High) that will create a copy of the installation with the bug fixed.

This app has a bug causing it to fail to resolve git functionality due to
some bad checks around Windows/WSL paths. See GitHub issue 35119.

Copy the installation, fix the relevant bugs, and create a launcher.

When you are finished, provide the launcher file name and a Windows path
link to its containing folder.

Before you launch the fixed version, make sure you have completely exited the other one. Check the system tray because it "closes" to there.

最新版本中仍然存在此错误26.727.40816。 作为临时解决方法，您可以向 GPT-5.6-Sol (High) 发出以下提示，这将创建一个修复了错误的安装副本。 `` This app has a bug causing it to fail to resolve git functionality due to some bad checks around Windows/WSL paths. See GitHub issue 35119. Copy the installation, fix the relevant bugs, and create a launcher. When you are finished, provide the launcher file name and a Windows path link to its containing folder. `` 在启动修复版本之前，请确保已完全退出旧版本。检查系统托盘，因为修复版本会关闭到那里。

Does it work?

Just want to also flag that I've been avoiding Codex Desktop for months due to issues with WSL2 git worktrees.. Plus far too much latency when it tries to write across the Windows-WSL2 bridge. Only running codex from within the CLI in WSL2 even though the desktop app's sidebar and UX would benefit me and my workflow.

I can't justify reinstalling Desktop, the mode/UX I'd prefer, until I'm confident WSL2 is well supported and works as expected.

019fa84a-6bfa-7ce2-b8b4-a22900eb4950 ID trace

I've uninstalled ChatGPT desktop app and went back to CLI because of this issue. Unbelievable the lack of support for windows and wsl features and bugs

Confirmed this persists on Microsoft Store package 26.730.8199.0 with app-server 0.147.0-alpha.1.2 on Windows + WSL.

This reproduction uses a repository under /mnt/c/... (the Windows-mounted filesystem), so it is not limited to WSL ext4 paths.

Desktop logs show both:

Failed to apply worktree shell environment config ... errorMessage="Git is unavailable"
worker_rpc_response_error ... method=turn-diff-capture-start workerId=git

But Git is healthy in the same WSL environment:

• git --version succeeds (2.43.0)
• git rev-parse --show-toplevel succeeds
• git worktree list --porcelain succeeds
• git worktree add -b <branch> <sibling/.worktrees/path> origin/main succeeds and creates a clean worktree tracking origin/main

So the failure remains isolated to the Desktop Git worker / WSL handoff, rather than Git, repository health, or worktree configuration.

Confirming that this remains reproducible on a much newer Windows Store build, with one additional cwd-level A/B result that may help narrow the precheck failure.

Environment

• Codex Desktop package: OpenAI.Codex_26.803.5235.0_x64
• App server: 0.147.0-alpha.6.5
• Windows 11 x64
• WSL2, Ubuntu 24.04
• Git in WSL: 2.43.0
• Repository: generic Git checkout on WSL ext4 under /home/<user>/<repo>

The repository is clean, its branch has a valid upstream, and the following all succeed in WSL:

git --version
git rev-parse --show-toplevel
git status --short --branch
git worktree list --porcelain

Desktop still reports:

git fetch failed: Git is unavailable
Failed to apply worktree shell environment config cwd=/home/<user>/<repo> errorMessage="Git is unavailable"
worker_rpc_response_error errorMessage="Git is unavailable" method=turn-diff-capture-start workerId=git

This persists after fully restarting Windows, WSL, Explorer, and Codex Desktop.

Additional precheck/cwd evidence

Static inspection of the installed Desktop bundle shows that the Git availability precheck obtains codexHome, platformFamily, and platformPath, derives a probe cwd from platformPath.parse(codexHome).root, and then sends the command through the Windows-to-WSL spawn wrapper.

That wrapper falls back to . when the derived cwd is empty and constructs a command equivalent to:

wsl.exe -d <distro> --cd <cwd> -- /usr/bin/bash -lc <command>

On this installation, the cwd behavior is:

--cd /        -> exit 0, git version 2.43.0
--cd /mnt/c/  -> exit 0, git version 2.43.0
--cd C:\      -> exit 0, git version 2.43.0
--cd .        -> exit 255, Wsl/E_INVALIDARG

The --cd . case fails before /bin/sh or Git starts. Replaying the packaged Git availability script with a valid absolute cwd such as / returns exit 0.

This is consistent with a Windows/WSL path-family mismatch producing an empty root for the availability probe, followed by the wrapper substituting a relative . that wsl.exe --cd rejects.

Suggested fix

For WSL spawns, normalize the probe cwd to an absolute Linux path before constructing wsl.exe --cd. If no absolute cwd can be derived, use /, ~, or omit --cd instead of passing ..

No repository-specific configuration appears involved; CLI Git continues to work normally on the same checkout.

One useful connection to the existing cwd diagnosis: this issue and #32323 are caused by two independent defaults in the same Windows-to-WSL argument builder.

For this issue, the Git availability precheck combines a Windows-form codexHome with the POSIX path parser selected for WSL. Parsing that value can produce an empty root; the wrapper then substitutes . and invokes:

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

I reproduced the packaged invocation from Windows Node with the Codex Desktop installation directory as the inherited Windows cwd. --cd . fails in wsl.exe with Wsl/E_INVALIDARG before the shell or Git starts; changing only the cwd to / makes the unchanged Git probe return git version 2.53.0 and exit 0.

The production fix should therefore make the precheck cwd absolute and valid for the selected execution host, and the WSL wrapper should never synthesize --cd .: use an absolute Linux cwd, or omit --cd when none is available. Bypassing the Git precheck is not necessary.

Separately, the same builder uses bare -- to delimit the command. At that boundary literal GraphQL $variables are expanded away, causing #32323; --exec preserves them. These should be fixed together in the shared WSL spawn path, while keeping the two failure modes independently testable.

Confirming this still reproduces on Codex Desktop package 26.803.5235.0 with Codex CLI 0.147.0, Windows 11, and WSL2 Ubuntu.

The same healthy WSL repository is misclassified by Desktop in two user-visible ways:

• Pull requests are not displayed correctly.
• Continue in a new worktree reports that a Git repository is required.

Git works normally in WSL, and native Git is also installed on Windows. Desktop logs repeatedly show:

GitHub operation failed errorMessage="Git is unavailable" errorName=GitUnavailableError

This blocks both the PR workflow and native Desktop worktrees, despite the repository and Git installations being healthy.

Same issue here. Repositories in windows filesystem get recognized but the ones in WSL do not.

Following up on my previous reproduction: this remains reproducible on the much newer Microsoft Store package OpenAI.Codex 26.814.5167.0, using Windows 11 + WSL2 Ubuntu.

The issue affects multiple valid repositories stored on the WSL ext4 filesystem under /home/<user>/....

Current evidence

Git remains healthy inside WSL:

git version 2.43.0
git rev-parse --is-inside-work-tree -> true

I also extracted and replayed the exact Git availability probe used by the installed Desktop bundle. When executed from the absolute WSL cwd /, it succeeds in approximately 0.01s with exit code 0.

Despite this, the Desktop project API reports multiple valid WSL repositories as:

isGitRepository: false

The fresh Desktop logs continue to show:

git fetch failed: Git is unavailable
Failed to apply worktree shell environment config
worker_rpc_response_error errorMessage="Git is unavailable" method=turn-diff-capture-start workerId=git

The logs also still contain bundled_executable_relocation_failed for the packaged WSL bwrap resource. As a controlled test, I placed a verified copy of the system bwrap binary at the expected relocation target, restarted Desktop completely, and reproduced the same Git failure. The test file was removed afterward, indicating that the missing relocation target is not the cause of the Git-worker failure.

Recovery attempts performed

• Updated WSL
• Executed wsl --shutdown
• Repaired Codex Desktop through Windows Settings
• Fully restarted Codex Desktop and Windows
• Verified both Linux Git and Git for Windows installations
• Replayed the packaged Git probe directly

None changed the result.

This now blocks Desktop worktrees and worktree-backed scheduled automations. Five affected automations remain paused to avoid running them against the wrong working directory or mixing changes into the main checkout.

This additional reproduction supports the existing diagnosis that the failure is in the Desktop Git worker / Windows-to-WSL spawn boundary, rather than Git, repository state, or the WSL installation.

I have a sanitized diagnostic bundle containing the relevant log excerpts, exact packaged probe output, automation state, and environment details available if maintainers would like it.

Confirmed the root cause and a fully working local fix (Store package 26.814.5167.0, 2026-08-18)

Same regression here. This comment documents (1) what did NOT help, (2) the exact root cause found by
inspecting the installed bundle, (3) a verified patch that restores Git detection and the PR/worktree
flows, plus a healthy app-server handshake, and (4) a suggested official fix.

Environment

• Windows 11 + WSL2 Ubuntu; Microsoft Store package OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
• WSL agent mode enabled (config.toml: [desktop] runCodexInWindowsSubsystemForLinux = true)
• Git inside WSL healthy: git --version -> 2.43.0, git rev-parse --show-toplevel, git status all fine
• Repos on both WSL ext4 (/home/<user>/Codes/...) and /mnt/c, /mnt/d affected
• One notable local detail: my WSL user's login shell is zsh (/etc/passwd: /usr/bin/zsh)

— this turned out to be relevant (see "second failure" below)

Symptoms (all identical to the thread)

• git fetch failed: Git is unavailable (recommended-skills)
• Failed to apply worktree shell environment config ... errorMessage="Git is unavailable"
• projects reported as isGitRepository: false, PR/worktree UI gone
• plus on my install: Codex app-server initialize handshake timed out every start

(app-server: "state db backfill is running at /mnt/c/Users/<user>/.codex; waiting up to 30s ..."),
and bundled_executable_relocation_failed ... bwrap ... ENOENT

What I tried that did NOT help

• Reset-AppxPackage / full reinstall from Store — no change
• The common "toggle WSL off" advice via .codex-global-state.json / runcodexinwindowssubsystemforlinux

— on a clean install that key does not even exist in .codex-global-state.json;
the real switch lives in config.toml [desktop], and disabling it only avoids WSL — it does not fix it

• wsl --shutdown, full Windows restart, repairing the app through Windows Settings, clearing ~/.codex
• checked /etc/wsl.conf, distro list, git installs on both sides — all healthy

Root cause (from the installed bundle, resources/app.asar)

The Windows-side git worker builds every WSL spawn like this (worker.js):

function BW(e){ return [`-d`, e.distro, `--cd`, e.cwd ?? `.`, `--`, PW, `-lc`, e.command] }

The Git availability probe passes cwd: platformPath.parse(codexHome).root. Since codexHome is the
Windows path C:\Users\<user>\.codex, parsing it with the POSIX parser yields an empty root, and the
spawn falls back to .:

cwd: i.parse(n).root,            // "" for a Windows path parsed as POSIX
// the spawn wrapper then does: cwd: n ? cW(n) : `.`   -> cwd = "."

The resulting command is

wsl.exe -d Ubuntu --cd . -- /usr/bin/bash -lc '<git probe>'

which fails with Wsl/E_INVALIDARG (exit 255) before the shell or git ever starts — reproduced
directly:

$ wsl.exe -d Ubuntu --cd . -- /usr/bin/bash -lc 'git --version'
=> exit 255, "Wsl/E_INVALIDARG"

Second, independent failure on machines with a non-bash default shell:
wsl.exe ... -- routes the remainder through the user's default Linux shell. My login shell is
zsh, and crossing that shell mangles the probe script (command substitution comes back empty):

$ wsl.exe -d Ubuntu --cd / -- /usr/bin/bash -lc 'g=$(command -v git); echo g=[$g]'   -> g=[]
$ wsl.exe -d Ubuntu --cd / -e /usr/bin/bash -lc 'g=$(command -v git); echo g=[$g]'   -> g=[/usr/bin/git]

So even fixing the cwd alone still fails here; the probe must also avoid the default-shell detour
(--exec). (This is the same flag user Freefor100 correctly identified for #32323.)

Replaying the full packaged probe with the fixed argv:

$ wsl.exe -d Ubuntu --cd / -e /usr/bin/bash -lc '<packaged probe>'
git version 2.43.0   (exit 0)

The fix that works (verified)

The runtime reads resources/app.asar directly (extracting to resources/app/ without the asar file
does not boot on this Chromium-based shell), so I:

1. copied the package to C:\Users\me\CodexDesktop-Fixed
2. patched the two bundled JS files (.vite/build/worker.js and .vite/build/src-DY9Aq019.js),

5 string sites total:

• in the spawn builders: e.cwd ?? '.' -> e.cwd ?? '/' and '--' -> '-e'

(worker.js BW, src-DY9Aq019.js nO)

• in the caller-side cwd fallbacks: cwd: n ? cW(n) : '.' (worker.js), cwd: r ? wD(r) : '.'

and cwd: e.repoRoot.trim().length>0 ? wD(e.repoRoot) : '.' (src-DY9Aq019.js) — all to '/'

1. repacked app.asar with @electron/asar, keeping the unpacked natives

(use --unpack '**/node_modules/**'; the CLI only honors the LAST --unpack flag,
so a single wide glob is needed)

1. launched app\ChatGPT.exe from the copy

Result (fresh desktop logs):

• initialize_handshake_result durationMs=821 outcome=success — was a 30 s timeout before
• Git is unavailable — 0 occurrences (was every start)
• git worker runs real commands on the projects: git ... config --get remote.origin.url, etc.;

[git-repo-watcher] Starting git repo watcher

• spawned WSL commands now look like

wsl.exe -d Ubuntu --cd /home/... -e /usr/bin/bash -lc ... (absolute cwd, --exec)

• the bwrap relocation error did not reappear

Caveats for anyone doing this: the copy has no MSIX identity, so the in-app auto-updater is disabled
(intentional; a future fixed Store release will need reinstalling, which is fine). Run only ONE copy at
a time — both share <USERPROFILE>\.codex. Keep the original app.asar for rollback.

Suggested official fix (same conclusion as the other comments)

In the shared Windows -> WSL spawn builder:

1. never emit --cd .: use an absolute Linux cwd, or fall back to / (or omit --cd) when none can be derived
2. use --exec instead of bare --; without it, users with non-bash default shells (e.g. zsh) hit a

second failure even after #1 is fixed

---

Anyway, you can dump the above diagnosis and solutions into Codex CLI or anything else to see if it can help.

Confirmed on current Windows package 26.814.5167.0 — root cause isolated and locally patched successfully.

Environment:

Windows 11 x64
WSL2 / Ubuntu
Codex package: OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
Agent runtime: WSL
Integrated terminal shell: WSL

Reproduction:

With Agent runtime = Windows, both PowerShell and WSL terminals work.
With Agent runtime = WSL, both PowerShell and WSL terminal options cause the bottom terminal panel to flash and immediately close.

I instrumented the shipped 26.814.5167.0 renderer and terminal session manager.

The immediate panel close is only cleanup. The actual failure is a terminal-host error:

Git is unavailable

The renderer receives the terminal error event, calls deleteSessionMapping(sessionId), the terminal session disappears from the conversation snapshot, and the bottom-panel cleanup then removes the terminal tab and closes the empty panel.

Importantly, Git itself is available inside the WSL terminal:

DISTRO=Ubuntu

/usr/bin/git

git version 2.43.0

I isolated the failing call in the main-process Terminal Manager initialization. The terminal receives a getWorktreeShellEnvironmentForCwd callback equivalent to:

async t => {
let r = await e.gitManager.getWorktreeRepository(n.ho(t), s);
return r == null ? null : n.X(r);
}

When getWorktreeRepository() throws Git is unavailable, this optional Git/worktree environment lookup aborts terminal creation.

I changed only this callback to fail open:

async t => {
try {
return (t = await e.gitManager.getWorktreeRepository(n.ho(t), s)) && n.X(t);
} catch {}
}

No renderer cleanup changes, routing changes, or terminal-session hacks are required.

After applying only this change to the original 26.814.5167.0 ASAR:

WSL Agent runtime works
integrated WSL terminal stays open
PTY is actually running inside Ubuntu/WSL2
uname, pwd, filesystem operations and /usr/bin/git all work normally

So for this reproduction, the terminal is being killed by an optional Git/worktree shell-environment lookup that throws instead of degrading to null.

This may also be related to #35119 (Git is unavailable in valid WSL repositories) and the older symptom report #25256.

A likely upstream fix is to make getWorktreeShellEnvironmentForCwd fail-open when Git/worktree detection is unavailable, rather than failing terminal creation.

Confirming that the second WSL spawn failure still reproduces on the newer Microsoft Store package OpenAI.Codex_26.818.3698.0_x64.

Environment

• Windows 11 + WSL2
• Distro: Ubuntu24
• Default Linux shell: /usr/bin/zsh
• Git: /usr/bin/git, version 2.43.0
• Repository stored on WSL ext4 under /home/...

The installed bundle still builds WSL commands in this form:

wsl.exe -d Ubuntu24 --cd / -- /usr/bin/bash -lc <quoted Git probe>

I replayed the exact packaged Git availability probe through the Windows Node runtime with an absolute, valid cwd (--cd /), so this A/B is independent of the previously diagnosed --cd . failure:

marker --       -> exit 126
                   /bin/sh: 1: exec: : Permission denied

marker --exec   -> exit 0
                   git version 2.43.0

marker -e       -> exit 0
                   git version 2.43.0

Capturing the target process argv shows the premature expansion directly. A simplified requested command:

exec /bin/sh -c 'git="$(command -v git)"; exec "$git" --version'

arrives at the intended target as:

exec /bin/sh -c 'git="/usr/bin/git"; exec "" --version'

For the full packaged probe, the target receives the equivalent of:

git="/usr/bin/git"
git_dir=""
git="/"
# ...
exec "" --version

This confirms that bare -- allows an earlier/default-shell expansion before the intended /usr/bin/bash -lc and inner /bin/sh run. Fixing only the cwd is therefore insufficient on this setup.

The shared WSL argument builder should use --exec (or -e) instead of bare --:

["-d", distro, "--cd", absoluteCwd, "--exec", "/usr/bin/bash", "-lc", command]

Microsoft documents --exec as executing the specified command without using the default Linux shell:
https://learn.microsoft.com/en-us/windows/wsl/release-notes#build-18305

The same failed availability probe still causes the integrated terminal to abort before PTY creation, matching #37962. No Windows Git, WSL Git, PATH, or repository-health issue is involved.

Current Store build 26.818.5229.0: WSL spawn boundary is still unfixed

Cross-linking the exact downstream terminal failure trace in #37962 and adding evidence from a newer installed package.

I inspected an isolated copy of OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0 (app.asar SHA-256 C5D839BC9B122B7EF2A2F0F45186B3E5895923DE5B6CEF5253C936FE670C0479). The two duplicated shared WSL builders still construct the equivalent of:

[`-d`, distro, `--cd`, cwd ?? `.`, `--`, bash, `-lc`, command]

The relevant builders still use bare --; they do not use --exec/-e. The cwd ?? '.' fallback also remains in both bundled copies.

The Git availability caller has gained a partial cwd fallback equivalent to:

cwd: platformPath.parse(codexHome).root || platformPath.sep

However, that does not fix the independently reproduced default-shell expansion problem documented above on 26.818.3698.0. The current 26.818.5229.0 builder still crosses the same bare--- boundary, so users whose default WSL shell alters the nested probe can still receive Git is unavailable even with an absolute / cwd.

The clean fix remains:

1. require a host-valid absolute Linux cwd and never emit --cd .;
2. invoke the target explicitly with --exec/-e and preserve argv boundaries;
3. regression-test Bash and Zsh default shells with the full packaged Git probe;
4. separately fail open when optional Git/worktree enrichment is used during terminal creation.

The last point is tracked with an exact failure chain, local A/B validation, production-style pseudocode, and requested regression coverage here: https://github.com/openai/codex/issues/37962#issuecomment-5391032851

This is a shared shipped Windows/WSL adapter defect, not a repository-health or Git-installation problem. Please link the internal fix/owner and identify the first Microsoft Store build expected to contain it.

I can no longer reproduce the WSL repository misclassification reported here with Microsoft Store package OpenAI.Codex_26.820.9563.0_arm64__2p2nqsd0c76g0.

Environment:

• Windows 11 ARM64
• WSL2 / Ubuntu
• Codex agent environment: WSL
• Default WSL login shell: /bin/bash
• Repository stored on the WSL ext4 filesystem under /home/<user>/...

Results:

• The Codex App project API reports the repository as isGitRepository: true.
• A new task using a native WSL worktree was created successfully under /home/<user>/.codex/worktrees/....
• In the Codex Desktop logs generated during this test, Git is unavailable and isGitRepository:false both had zero occurrences.

I have not tested this build with zsh as the default WSL login shell. Because later comments report a separate failure affecting zsh configurations, this result only confirms the /bin/bash environment described above.