MoonshotAI / MoonshotAI/kimi-code

VS Code extension: Bash tool returns exit 0 but stdout is always empty (WSL2)

Open
#2,426 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

Summary

In the VS Code extension (moonshot-ai.kimi-code 0.6.6, running on the WSL remote server), the Bash tool executes commands and reports exit 0, but the tool result handed back to the model contains no stdout — only the literal string Command executed successfully.

The same CLI binary (0.31.0) captures stdout correctly when used as a terminal CLI in the same working directory.

Environment

  • VS Code extension: moonshot-ai.kimi-code 0.6.6 (linux-x64), activated on the WSL remote (remote: wsl)
  • CLI: kimi-code 0.31.0 (~/.kimi-code/bin/kimi)
  • Host: Windows 11 + WSL2, kernel 6.18.33.2-microsoft-standard-WSL2, Ubuntu userland
  • Extension host env includes SHELL=/usr/bin/zsh, TERM_PROGRAM=vscode
  • Permission mode: manual (auto mode disabled); commands were approved via the permission prompt

Evidence

From the extension session's wire file (~/.kimi-code/sessions/<wd>/<session>/agents/main/wire.jsonl), an approved ls . call records:

{"type": "tool.call", "name": "Bash", "args": {"command": "ls ."}}
{"type": "tool.result", "toolCallId": "tool_NcuQOd43Ul7hozch48nRHGdG",
 "result": {"output": "Command executed successfully."}}

Same for a second approved command (pwd && ls -1 | head -5) — exit 0, stdout missing. The directory is not empty; a CLI session in the same directory returns full listings.

What I ruled out

  • SHELL value: reproducing with SHELL=/usr/bin/zsh kimi -p "run echo MARKER..." in the terminal captures stdout fine.
  • CLI itself: both uiMode=shell (interactive CLI) and uiMode=print (kimi -p) return stdout correctly on the same machine, same project, same binary.
  • VS Code user settings: no kimi/terminal settings that affect bash.

So the stdout loss happens only on the extension ↔ backend path (bridge mode), not in the CLI's bash execution itself.

Repro

  1. Open VS Code connected to a WSL2 workspace.
  2. In the Kimi Code panel, ask the agent to run a bash command, e.g. ls ..
  3. Approve the permission prompt.
  4. The agent reports the command ran with exit 0 but sees no output.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the extension↔backend bridge path for the Bash tool and compare it with the CLI execution path. Use the wire file at ~/.kimi-code/sessions///agents/main/wire.jsonl and reproduce with ls . or pwd && ls -1 | head -5; done means the tool result handed to the model contains the command's stdout instead of only the success message.

Written by the indexing model from the issue text.

Assessment

Tech stack
shell, typescript, vscode
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.