Kilo CLI uses Linux commands in tool calls when running on Windows

[doxxx]

Description

I'm running Kilo CLI (installed via npm) on Windows 11. Using the Orchestrator agent, I'm giving it a prompt to implement a feature. In the various sub-agents that Orchestrator launches, it is performing command-line tool calls using bash which looks like it is actually launching WSL since that's what bash at the Windows command-line launches.

In this particular example, it executed dir "C:\Path\To\My\Project" /a (with backslashes) which failed with: /usr/bin/bash: -c: line 1: unexpected EOF while looking for matching "'. It then switched to using ls -la` but still with a Windows path using forward slashes, which just happens to work in WSL.

Plugins

No response

Kilo version

Kilo CLI 1.0.23

Steps to reproduce

1. Launch Kilo CLI on Windows.
2. Give a prompt to the Orchestrator agent that requires inspecting and modifying files.

Screenshot and/or share link

No response

Operating System

Windows 11

Terminal

Windows Terminal

[github-actions]

This issue appears to be related to the broader Windows path handling issues tracked in #6332. The problems you're experiencing with backslashes and path escaping in bash tool calls are part of a larger set of Windows filepath challenges documented there.

Please check #6332 to see if your issue is already being addressed as part of that effort, and feel free to add any additional details or test cases that might help resolve the Windows path handling problems.

[doxxx]

I disagree that it's simply about Windows file paths. It shouldn't be executing bash to run shell commands on Windows.

[doxxx]

It's also wasting a lot of tokens on these errors and various syntax errors as it tries different commands.

[doxxx]

One more data point: I'm using Kilo CLI with my Github Copilot subscription using the Claude Sonnet 4.6 model.

[doxxx]

It's also creating nul files in the root of my workspace. Most likely because it's trying execute Windows-like commands, e.g. dir some\path 2>nul which would redirect errors to the NUL device but because it's using bash to execute the command, WSL doesn't know about the Windows NUL device and just creates a nul file with the redirected output.

[doxxx]

Actually, it looks like it's running Git Bash? The commands it was trying succeed (mostly) in Git Bash but not in WSL. However, it looks like it was trying to run CMD commands (e.g. dir C;\path\to\repo /a 2>nul). While Git Bash has a dir executable that does the right thing, the redirect to the NUL device is not correct for Git Bash.

[pschiel]

the CLI needs a shell to run commands, on Windows this can be:

• Git Bash (preferred way, native, comes with install Git for Windows)
• WSL Bash (but WSL not compatible with Windows paths and other issues, similar to Docker)
• cmd.exe or powershell/pwsh

If you run Git Bash and the agent is trying to run "dir" commands, it's most likely due to the "Platform: win32" environment info from the system prompt being a bit vague.

You can fix this by adding instructions in your AGENTS.md, that you're running a Git Bash on Windows, and to avoid backslashes in paths.

A few other path issues need Kilo-Org/kilo#108 to fix.

If you still absolutely want cmd.exe or pwsh (while having git bash or wsl installed), you can override SHELL and KILO_GIT_BASH_PATH environment variables to point to their absolute paths

[doxxx]

IMO, Kilo CLI should use the native tools for the platform, i.e. PowerShell on Windows, bash on Linux/macOS. Depending on having Git Bash installed seems a little sketchy. I'd also argue that it's Kilo CLI's responsibility to give the necessary system instructions so that the model knows what platform and shell it should be generating commands for.

[pschiel]

IMO, Kilo CLI should use the native tools for the platform, i.e. PowerShell on Windows, bash on Linux/macOS. Depending on having Git Bash installed seems a little sketchy. I'd also argue that it's Kilo CLI's responsibility to give the necessary system instructions so that the model knows what platform and shell it should be generating commands for.

Opencode and Kilo are hard depending on git for a lot of functions, Git Bash isn't sketchy it's the default. If you want to argue and insist on backslashes and cmd.exe - have fun. You will run into dozens of bugs

[doxxx]

I'm not arguing for cmd.exe -- it's a deadend. That's why I suggested PowerShell. And it handles forward slashes in paths just fine.

Regardless of what shell it's using, the model is not being prompted correctly and so it's flailing around generating the wrong commands for the shell and platform. I shouldn't have to tell it in my prompt or instruction files what operating system and shell it's generatintg commands for. The agent framework (i.e. Kilo CLI) should be doing that.

[doxxx]

Also, my point about depending on Git Bash being installed is that it is a perfectly valid scenario to not have Git Bash installed and having Kilo CLI be broken in that scenario just seems be a poor design decision.

[pschiel]

Also, my point about depending on Git Bash being installed is that it is a perfectly valid scenario to not have Git Bash installed and having Kilo CLI be broken in that scenario just seems be a poor design decision.

Of course that's fine. Your concrete problem was that your CLI uses git bash currently, but the agent tried to run cmd.exe commands, having only the info that it runs on win32.

This patch should help, it adds the path of the current used shell to the environment system prompt: Kilo-Org/kilo#573