bug(tui): status_line.command containing quotes always fails on Windows (cmd /s quote-stripping) — silent fallback to built-in footer

Bug: status_line.command containing quotes always fails on Windows — silent fallback to built-in footer

Summary

On Windows, any [status_line].command in tui.toml that quotes its arguments (e.g. a path to the script) never runs. The child process exits with code 2 within ~40 ms, stderr is discarded, and the footer silently falls back to the built-in layout — so from the user's perspective the config "does nothing", with no error anywhere.

Root cause

runStatusLineCommand (apps/kimi-code/src/tui/utils/status-line-command.ts) spawns the command like this on Windows:

child = spawn(process.env['ComSpec'] ?? 'cmd.exe', ['/d', '/s', '/c', command], ...)

Node's spawn joins the argv into a command line and wraps command in double quotes because it contains spaces, producing:

cmd.exe /d /s /c "python \"C:/Users/<user>/.kimi-code/statusline.py\""

With cmd /s, if the string after /c starts with a quote, cmd strips the first and last quote only — the inner \" escapes remain as literal characters. Python therefore receives the path as the literal string \"C:/Users/<user>/.kimi-code/statusline.py\" (backslash + quotes included) and fails:

python: can't open file 'C:\Users\<user>\"C:\Users\<user>\.kimi-code\statusline.py"': [Errno 22] Invalid argument

Exit code 2 → runStatusLineCommand resolves null → built-in footer. Stderr is ignored, so the failure is completely invisible.

Reproduction

Verified on this machine (Windows 11, kimi 0.39.1) with an exact Node replica of runStatusLineCommand (same argv, same stdio, same env, same 300 ms timeout):

Failing command (tui.toml as generated by tooling):

[status_line]
command = "python \"C:/Users/17141/.kimi-code/kimi-statusline-custom.py\""

Replica result: close code=2 elapsed=39ms firstLineLen=0 — python starts, can't open the mangled path, exits 2. A process watcher confirms the TUI spawns cmd /d /s /c "python \"C:/...\"" roughly once per second and the child python.exe exits ~200 ms with no side effects.

Working command (quotes removed, absolute interpreter path):

[status_line]
command = "C:/Users/17141/AppData/Local/Programs/Python/Python312/python.exe C:/Users/17141/.kimi-code/kimi-statusline-custom.py"

Replica result: close code=0 elapsed=118ms firstLineLen=477 — first stdout line contains the rendered status line and the footer displays it correctly after /reload-tui.

Note the workaround only helps while no path segment contains spaces — a script under e.g. C:/Users/me/my tools/sl.py cannot be quoted at all, so it breaks again.

Suggested fixes

Any one of:

1. Don't wrap command in quotes when building the cmd argv (pass it so that cmd receives the raw string), or
2. Pre-sanitize: on Windows, strip/replace inner \" escapes before spawning, or
3. Run the command via process.env.ComSpec with /c (no /s) and no outer quoting, letting cmd apply its default quote handling, or
4. At minimum, surface the non-zero exit/stderr in the TUI status area so misconfigured commands don't fail silently.

Environment

• OS: Windows 11 (also reproduced from Git Bash, Windows Terminal, and direct Node spawn — terminal-independent)
• kimi-code: 0.39.1 (binary dated 2026-09-01; feature introduced in 0.30.0 via #2255 and unchanged since)
• The relevant code path has had no commits since the original feature PR, so all versions ≥ 0.30.0 are affected.

Diagnosis trail (for reference)

Caught by cross-checking three independent observations: (1) kimi doctor tui validates the config and the command succeeds in every manual invocation (~120 ms, exit 0); (2) a WMI process watcher showed the TUI spawning the command every 1–3 s with the real python.exe starting and exiting ~200 ms; (3) the script produced zero side effects on disk, meaning python never actually executed it — pointing to argv mangling rather than PATH/timeout issues.

Start in apps/kimi-code/src/tui/utils/status-line-command.ts at runStatusLineCommand, then reproduce the quoted Windows command from the issue. Trace how the command is passed to ComSpec and verify that quoted script paths, including paths with spaces, execute and render the status line instead of falling back silently.