cd /d/... (Git-Bash/MSYS-style drive paths) fails on Windows while ls accepts them

[arynyklas]

Description

On native Windows, the bundled bash (brush) does not resolve Unix/Git-Bash–style drive-letter paths such as /d/..., /c/..., or WSL-style /mnt/d/... in cd. Models routinely emit these — they translate D:\ → /d/ out of habit — so cd /d/<...> fails for the agent on essentially every turn that changes directory.

The real problem is that path handling is inconsistent within the same shell: the in-process ls/glob layer does map /d/... to the D: drive, but the cd builtin and stat-based builtins (test -d, [ -d ]) do not. As a result a normal cd /d/project/sub && <cmd> aborts at the cd, even though ls /d/project/sub on its own works. omp's own system prompt reports the cwd as D:/project, yet the model still produces /d/project, and only some tools accept it.

Steps to Reproduce

1. On native Windows, start omp in a directory on any drive, e.g. D:\project (omp displays it as D:/project).
2. In the bash tool, run a directory listing with a Unix-style drive path — it works:

   ls /d/project        # lists D:\project correctly
   

3. Now try to cd into the same path — it fails:

   cd /d/project/app
   

4. The MSYS (/c/) and WSL (/mnt/d/) conventions also fail:

   cd /c/
   cd /mnt/d/project
   

5. Native Windows forms work fine:

   cd D:/project/app   # ok
   cd 'D:\project'     # ok
   

6. Passing cwd: "/d/project" to the bash tool is also rejected at the tool layer.

Expected Behavior

Drive-letter paths should resolve consistently across all builtins. Either:

• brush emulates the Git-Bash/MSYS drive mapping (/d/... → D:\..., and ideally /mnt/d/...) everywhere, so cd /d/... behaves like ls /d/... already does; or
• the harness normalizes /d/...-style paths to native D:\... before they reach cd/stat.

At minimum, ls and cd must not disagree about whether /d/project exists.

Error Output

$ ls /d/project           # works
dir-a
dir-b
app
...

$ cd /d/project/app       # brush cd builtin
error: cd: i/o error: The system cannot find the path specified. (os error 3)

$ cd /c/
error: cd: i/o error: The system cannot find the file specified. (os error 2)

$ cd /mnt/d/project
error: cd: i/o error: The system cannot find the path specified. (os error 3)

# bash tool with cwd="/d/project":
Working directory does not exist: /d/project

Platform

Windows (native)

omp version

15.12.4

Bun version

1.3.10

Provider

Not provider-specific (reproduced via the bash/brush tool layer; independent of model/provider).

Area

Tool execution

Additional context

• omp reports the cwd as D:/project in the system prompt, but models still translate it to /d/project; combined with ls accepting /d/... and cd rejecting it, this makes the failure intermittent and confusing.

• Behavior matrix observed:

  command	result
  ls /d/project, ls /d	✅ lists the D: drive
  cd D:/project/app, cd D:\project	✅
  cd /d/project/app, cd /D/project	❌ os error 3
  cd /c/	❌ os error 2
  cd /mnt/d/project	❌ os error 3
  bash tool cwd: /d/project	❌ "Working directory does not exist"

[roboomp]

Looking into this; I’ll report back with a focused repro for the Windows /d/... and /mnt/d/... path handling mismatch.

[roboomp]

Repro found on the tool-layer path resolver: resolveToCwd("/d/project", "D:/project") currently returns /d/project unchanged, so the bash tool validates the MSYS-style cwd with fs.stat instead of first converting it to D:/project. I’m checking the matching brush cd/test -d path now.

[roboomp]

Fix opened in #2635.