Bash tool fails to spawn (ENOENT) when session workspace is a WSL UNC path

Summary

On Windows, when a Kimi Work session workspace points to a WSL directory via its UNC path (\\wsl.localhost\<distro>\...), every Bash tool call fails immediately with:

spawn C:\Users\<user>\AppData\Roaming\kimi-desktop\daimon-bundle\runtime\git\bin\bash.exe ENOENT

Environment

• OS: Windows 11, WSL2 (Ubuntu) installed and running
• Kimi desktop app, bundle at %APPDATA%\kimi-desktop\daimon-bundle

Steps to reproduce

1. Open a session whose workspace is \\wsl.localhost\Ubuntu\home\<user>\project.
2. Ask the agent to run any Bash command (e.g. echo ok).

Expected

Bash executes the command.

Actual

spawn ...daimon-bundle\runtime\git\bin\bash.exe ENOENT on every call, before any process starts.

Diagnostics already collected

• bash.exe exists at the reported path and launches manually (MINGW64 prompt works).
• Bundle integrity verified: bin/bash.exe, usr/bin/msys-2.0.dll, msys-iconv-2.dll, msys-intl-8.dll are present — same set as a system Git for Windows installation (C:\Program Files\Git), which works fine.
• Deleting the bundle and letting the app re-download it does not help.
• Passing an explicit Windows cwd (e.g. C:\Users\Mi) to the tool call does not help — the error is identical, which suggests the spawner always uses the session workspace as the process cwd and ignores the override.
• In sessions whose workspace is a plain Windows path, the Bash tool works fine.

Hypothesis: the runtime passes the UNC workspace path as cwd to spawn; Node/libuv cannot resolve a UNC working directory and reports UV__ENOENT attributed to the executable path — which makes the error message point at bash.exe instead of the actual failing cwd.

Suggested fix

• Translate or reject UNC workspace paths before spawn: fall back to a valid default cwd (%USERPROFILE%) when the workspace is not a local Win32 directory, and/or run commands through wsl.exe when the workspace is a WSL path.
• Improve the error message to include the actual failing cwd, not just the executable path.

No source file or test is named. Start by tracing the Bash tool's spawn call and how the session workspace becomes the process cwd, then reproduce with a WSL UNC workspace and a plain Windows workspace. Done means Bash commands run from the affected workspace or the failure clearly reports the invalid cwd, with coverage for both workspace types.