MoonshotAI / MoonshotAI/kimi-code

VS Code extension ignores non-primary folders in multi-root workspaces

Open Beginner friendly
#3,221 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

What version of Kimi Code is running?

VS Code extension 0.7.0 (moonshot-ai.kimi-code)

Which open platform/subscription were you using?

Kimi Allegro

Which model were you using?

K3 High

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

When a VS Code window is opened as a multi-root workspace (.code-workspace with several folders), the Kimi Code extension starts the agent session with only the first workspace folder as its working directory. All other workspace folders are invisible to the agent: file tools cannot read or write them, and the model is not told they exist.

The CLI already supports this scenario (--add-dir, /add-dir, [workspace] additional_dir in local.toml), and the Node SDK exposes CreateSessionOptions.additionalDirs — but the VS Code extension never passes the remaining workspaceFolders through. In apps/vscode/src/bridge-handler.ts only workspace.workspaceFolders?.[0] is read to compute workDir; folders [1..] are dropped.

What steps can reproduce the bug?
  1. In VS Code: File → Add Folder to Workspace…, add a second folder; save as a .code-workspace and reopen it (two or more root folders in the Explorer).
  2. Open Kimi Code in that window and start a new session.
  3. Ask the agent to read a file that lives in the second workspace folder (by absolute path), or to list the workspace roots.

Actual: the agent's working directory is the first folder only; files in the other folders are outside its scope (path access denied / not visible) unless the user manually runs /add-dir for each folder.

What is the expected behavior?

On session start the extension should pass workspaceFolders[1..] to the session as additional directories (ephemeral, per-session — same semantics as /add-dir), so the agent can work with all workspace roots without any manual setup. cwd stays on the primary folder, which is correct as the anchor for terminals and file pickers.

This matches what other agent extensions do — e.g. Claude Code's VS Code extension collects vscode.workspace.workspaceFolders, keeps the first as cwd, and passes the rest as additionalDirectories to its SDK at spawn time.

Additional information
  • Root cause (current main): apps/vscode/src/bridge-handler.ts computes workDir from workspace.workspaceFolders?.[0]?.uri only; KimiRuntime.openSession (apps/vscode/src/runtime/kimi-runtime.ts) calls harness.createSession({ workDir, ... }) without additionalDirs. Same for the resume path.
  • The engine side needs no changes: CreateSessionOptions.additionalDirs / ResumeSessionInput.additionalDirs already merge into the session and surface as the ## Additional Directories system-prompt section.
  • Proposed fix (2 files, VS Code app only): read workspace.workspaceFolders.slice(1) in bridge-handler.ts, add additionalDirs to OpenSessionOptions in kimi-runtime.ts, and pass it to both createSession and resumeSession (the additional-dirs set is ephemeral in v2, so it must be re-sent on every create/resume).
  • Related: #1287 (multi-root workspaces over ACP) — same gap in a different frontend.
  • For comparison, this is what Claude Code's VS Code extension puts into the agent's system prompt in a multi-root window (verified on all current Claude models; paths anonymized):
# Environment
You have been invoked in the following environment:
 - Primary working directory: /path/to/primary-folder
 - Is a git repository: false
 - Additional working directories:
  - /path/to/second-folder
  - /path/to/third-folder
 - Platform: darwin

All workspace folders reach the model as plain system-prompt lines, uniformly across models — a good target behavior for Kimi Code as well.

Contribution
  • I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)

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 in apps/vscode/src/bridge-handler.ts, where the primary workspace folder is selected, then trace OpenSessionOptions through apps/vscode/src/runtime/kimi-runtime.ts for both create and resume paths. Verify the additional workspace folders are passed for each session while the first remains the working directory, and reproduce the behavior with a multi-root VS Code workspace.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript, vscode
Domain
developer-experience, tooling
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
88/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.