Skip to content

[Bug]: Windows file tools misresolve POSIX drive paths #111620

Description

@ooiuuii

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On native Windows, agent file tools cannot read existing files when a Git Bash, Cygwin, or WSL-style drive path is supplied because the shared path resolver maps the path under the current drive root instead of the requested drive.

Steps to reproduce

  1. Run OpenClaw from source on native Windows.
  2. Choose an existing file, for example F:\repo\package.json.
  3. Call the agent read tool with /f/repo/package.json, /cygdrive/f/repo/package.json, or /mnt/f/repo/package.json.
  4. Observe that each call fails before reading the existing file.

Expected behavior

Each supported POSIX drive spelling resolves to F:\repo\package.json and the read tool returns the file contents.

Actual behavior

The resolver treats each input as a current-drive-root path. The three examples attempt F:\f\repo\package.json, F:\cygdrive\f\repo\package.json, and F:\mnt\f\repo\package.json, then fail with ENOENT.

OpenClaw version

2026.7.2 (source checkout a20e08a)

Operating system

Windows 11 Pro, build 26200

Install method

pnpm source checkout

Model

N/A (the failure occurs in file path resolution before model/provider I/O)

Provider / routing chain

N/A (local agent file tool)

Additional provider/model setup details

N/A

Logs

{"input":"/f/repo/package.json","ok":false,"error":"ENOENT ... access 'F:\\f\\repo\\package.json'"}
{"input":"/cygdrive/f/repo/package.json","ok":false,"error":"ENOENT ... access 'F:\\cygdrive\\f\\repo\\package.json'"}
{"input":"/mnt/f/repo/package.json","ok":false,"error":"ENOENT ... access 'F:\\mnt\\f\\repo\\package.json'"}

Screenshots, recordings, and evidence

A deterministic source-level reproduction through createReadToolDefinition fails for all three inputs on the unmodified checkout. The same command succeeds for all three after normalizing recognized POSIX drive forms at the shared file-tool path boundary.

Impact and severity

Affected: native Windows users whose agent receives a path copied or emitted from Git Bash, Cygwin, or WSL.
Severity: blocks read/edit/write workflows for the affected path.
Frequency: 3/3 supported path forms reproduced consistently.
Consequence: the agent reports that an existing file does not exist and cannot continue file work until the user rewrites the path manually.

Additional information

UNC paths and ordinary POSIX paths such as //server/share, /home/..., and /tmp/... are not part of this bug and should remain unchanged.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:bulk-filedClawSweeper detected a high recent issue-filing volume from this author.clawsweeper:linked-pr-openClawSweeper found an open linked pull request for this issue.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:otherThis issue has meaningful maintainer-visible impact outside the owned taxonomy.impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions