git_bash MCP ignores OMO_CODEX_GIT_BASH_PATH and resolves WSL bash.exe

[ThisCCL]

Summary

The git_bash MCP resolves C:\Windows\System32\bash.exe even when OMO_CODEX_GIT_BASH_PATH is set to a valid Git Bash executable at D:\Program Files\Git\bin\bash.exe. On this Windows machine, C:\Windows\System32\bash.exe is the WSL launcher, so the MCP ends up using WSL2 bash instead of Git Bash.

Environment

• OS: Windows native Codex session, with WSL2 installed
• Git Bash path: D:\Program Files\Git\bin\bash.exe
• Relevant config: OMO_CODEX_GIT_BASH_PATH=D:\Program Files\Git\bin\bash.exe
• GitHub CLI: gh version 2.92.0 (2026-04-28)
• Affected surface: OMO/LazyCodex git_bash MCP

Reproduction

1. Set OMO_CODEX_GIT_BASH_PATH to D:\Program Files\Git\bin\bash.exe.
2. Start a Windows native Codex session with the OMO git_bash MCP enabled.
3. Call mcp__git_bash.which_bash or mcp__git_bash.diagnose.

Expected Behavior

The MCP should prefer the configured OMO_CODEX_GIT_BASH_PATH and resolve:

D:\Program Files\Git\bin\bash.exe

It should not select the WSL launcher from C:\Windows\System32\bash.exe when an explicit Git Bash path is configured and exists.

Actual Behavior

mcp__git_bash.which_bash returned:

{
  "found": true,
  "path": "C:\\Windows\\System32\\bash.exe",
  "source": "path"
}

mcp__git_bash.diagnose returned:

{
  "platform": "win32",
  "enabled": true,
  "status": "ready",
  "resolution": {
    "found": true,
    "path": "C:\\Windows\\System32\\bash.exe",
    "source": "path"
  }
}

PowerShell in the same session can see the intended environment variable and the target executable exists:

Process OMO_CODEX_GIT_BASH_PATH=D:\Program Files\Git\bin\bash.exe
User OMO_CODEX_GIT_BASH_PATH=D:\Program Files\Git\bin\bash.exe
Machine OMO_CODEX_GIT_BASH_PATH=
Test-Path D:\Program Files\Git\bin\bash.exe => True

where.exe bash shows why the fallback is dangerous on this host:

C:\Windows\System32\bash.exe
C:\Users\tanghao\AppData\Local\Microsoft\WindowsApps\bash.exe

Evidence

• The MCP reports source: "path", not source: "env", despite OMO_CODEX_GIT_BASH_PATH being set in the process and user environment.
• The configured path exists and points to a Git Bash executable.
• The selected fallback path is C:\Windows\System32\bash.exe, which is the WSL launcher on this machine.

Root Cause

The exact implementation cause still needs maintainer confirmation, but the observed behavior indicates that the environment used by the git_bash MCP process does not honor or receive OMO_CODEX_GIT_BASH_PATH, so resolution falls through to where bash and accepts the first bash.exe on PATH. On Windows systems with WSL installed, that can be C:\Windows\System32\bash.exe, which is not Git Bash.

Proposed Fix

• Ensure the MCP server receives and checks OMO_CODEX_GIT_BASH_PATH before PATH fallback.
• Reject known non-Git-Bash launchers such as C:\Windows\System32\bash.exe and WindowsApps bash.exe when resolving Git Bash.
• Consider validating candidates by executable location or a lightweight bash --version check that distinguishes Git for Windows from WSL.
• Surface checked paths in diagnose even when a PATH candidate is accepted, so this class of issue is easier to debug.

Verification Plan

• With OMO_CODEX_GIT_BASH_PATH=D:\Program Files\Git\bin\bash.exe, mcp__git_bash.which_bash returns that path with source: "env".
• With WSL installed and C:\Windows\System32\bash.exe first on PATH, the MCP does not accept it as Git Bash.
• With no env var and a standard Git for Windows install, the MCP still resolves the normal Git Bash path.

---

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated

[code-yeongyu]

Fixed in code-yeongyu/oh-my-openagent@5dafddb9d (dev, will ship in the next release). Three changes:

1. WSL launcher rejection — the PATH fallback now skips any bash.exe under \Windows\System32\ or \Microsoft\WindowsApps\ (case-insensitive, both slash styles), in both the MCP resolver and the installer's copy. A real Git Bash later on PATH (e.g. D:\…\Git\bin\bash.exe) still resolves with source: "path".
2. Env forwarding — you were right that the env var never reached the server: Codex spawns plugin MCP servers with a restricted environment. The installer now stamps OMO_CODEX_GIT_BASH_PATH into the cached plugin's .mcp.json git_bash server env during install/update, so set the variable and re-run lazycodex install (or wait for auto-update) and which_bash will report source: "env".
3. Debuggability — which_bash and diagnose now include checkedPaths even on successful resolution, so a wrong winner is visible immediately.

Replayed your exact machine setup (System32 + WindowsApps on PATH, Git on D:) against the built artifact: resolution no longer accepts the WSL launcher.