What version of Kimi Code is running?
0.29.1
Which open platform/subscription were you using?
Kimi Code
Which model were you using?
Kimi K3
What platform is your computer?
No response
What issue are you seeing?
On Windows, the Bash tool runs through Git Bash. When a bash command creates a file under a root-relative POSIX path such as /tmp, the built-in file tools cannot open that same path: Read reports that the file does not exist, even though the file was just created successfully and cat in bash shows its content.
There is also a worse variant: Write/Edit against such a path does not fail — it silently creates a new, empty file at the wrong location (e.g. C:\tmp\note.txt) instead of touching the file bash created.
What steps can reproduce the bug?
-
On Windows, in a Kimi Code session, ask the agent:
Run echo hello > /tmp/kimi-repro.txt && cat /tmp/kimi-repro.txt with the Bash tool, then read that file.
-
The Bash call succeeds and prints hello (the file is created under the user's Windows temp directory, which is where Git Bash mounts /tmp).
-
The agent then calls Read with path /tmp/kimi-repro.txt.
-
Read fails with a file-not-found error, because the path is resolved against the current drive root (C:\tmp\kimi-repro.txt) instead of the directory Git Bash actually used.
What is the expected behavior?
File tools should resolve Git Bash POSIX paths the same way the shell does — /tmp/kimi-repro.txt should open the file the Bash tool just created. Drive-letter forms (/c/...) already work today; root-relative paths like /tmp and /home should work too, or at minimum fail loudly instead of resolving to a wrong location.
Additional information
Root cause: the POSIX→Win32 mapping lives inside the msys-2.0.dll mount table and varies by installation (Git for Windows mounts /tmp to %TEMP% via a usertemp fstab entry; MSYS2 uses <install-root>\tmp; /etc/fstab is user-configurable), so it cannot be derived lexically. MSYS2's documentation names cygpath as the supported conversion tool, and native tools interoperating with Git Bash (CMake, Gradle, opencode) resolve such paths through cygpath -w located next to the git/bash binary.
I have a fix ready: a small shell path bridge at the file-tool boundary — lexical translation for the drive-letter forms (zero I/O), cygpath -w for root-relative paths. Command text is never rewritten, and every failure mode falls back to today's behavior, so no working case can regress. Happy to open a PR if the approach looks right.
What version of Kimi Code is running?
0.29.1
Which open platform/subscription were you using?
Kimi Code
Which model were you using?
Kimi K3
What platform is your computer?
No response
What issue are you seeing?
On Windows, the Bash tool runs through Git Bash. When a bash command creates a file under a root-relative POSIX path such as
/tmp, the built-in file tools cannot open that same path:Readreports that the file does not exist, even though the file was just created successfully andcatin bash shows its content.There is also a worse variant:
Write/Editagainst such a path does not fail — it silently creates a new, empty file at the wrong location (e.g.C:\tmp\note.txt) instead of touching the file bash created.What steps can reproduce the bug?
On Windows, in a Kimi Code session, ask the agent:
The Bash call succeeds and prints
hello(the file is created under the user's Windows temp directory, which is where Git Bash mounts/tmp).The agent then calls
Readwith path/tmp/kimi-repro.txt.Readfails with a file-not-found error, because the path is resolved against the current drive root (C:\tmp\kimi-repro.txt) instead of the directory Git Bash actually used.What is the expected behavior?
File tools should resolve Git Bash POSIX paths the same way the shell does —
/tmp/kimi-repro.txtshould open the file the Bash tool just created. Drive-letter forms (/c/...) already work today; root-relative paths like/tmpand/homeshould work too, or at minimum fail loudly instead of resolving to a wrong location.Additional information
Root cause: the POSIX→Win32 mapping lives inside the msys-2.0.dll mount table and varies by installation (Git for Windows mounts
/tmpto%TEMP%via ausertempfstab entry; MSYS2 uses<install-root>\tmp;/etc/fstabis user-configurable), so it cannot be derived lexically. MSYS2's documentation namescygpathas the supported conversion tool, and native tools interoperating with Git Bash (CMake, Gradle, opencode) resolve such paths throughcygpath -wlocated next to the git/bash binary.I have a fix ready: a small shell path bridge at the file-tool boundary — lexical translation for the drive-letter forms (zero I/O),
cygpath -wfor root-relative paths. Command text is never rewritten, and every failure mode falls back to today's behavior, so no working case can regress. Happy to open a PR if the approach looks right.