`kimi web` starts MCP servers from the CLI installation directory, breaking workspace-relative MCP tools

[Zehee]

What version of Kimi Code is running?

0.18.0

Which open platform/subscription were you using?

kimi-code

Which model were you using?

kimi-k2.7 thinking

What platform is your computer?

win11 X64

What issue are you seeing?

Summary

When launching a session via kimi web, Kimi Code CLI spawns the MCP server process from its own installation directory (~/.kimi-code/server) instead of the user's current project directory. Any MCP server that derives its workspace/storage path from process.cwd() at startup ends up writing data to a server-side workspace rather than the project workspace.

Session-context tools still work because they resolve the active session at request time using runtime process.cwd() plus the cached sessionMappings, but storage-oriented tools (memory, notes, etc.) are misrouted.

Root Cause

mcp-server.js computes its workspace at module-load time:

const cwd = process.cwd();
function computeWorkspaceId() {
  const hash = crypto.createHash('sha256').update(cwd).digest('hex').slice(0, 8);
  return `workspace-${hash}`;
}
const workspaceId = computeWorkspaceId();
const storeRoot = path.join(__dirname, 'store', workspaceId);

• With local kimi launched from the project directory, cwd is the project directory → correct workspace.
• With kimi web, the same server process is started from ~/.kimi-code/server → cwd becomes the server directory → wrong workspace (workspace-<server-hash> instead of workspace-<project-hash>).

The session-discovery code path avoids this because it calls process.cwd() on each request and looks up sessionMappings in mcp-config.json, but storage code paths do not re-evaluate the workspace.

What steps can reproduce the bug?

Steps to Reproduce

1. Create or install an MCP server whose workspace/storage directory is derived from process.cwd() at startup (e.g., a memory MCP that stores files under store/workspace-<cwd-hash>/).
2. Register it with Kimi Code CLI.
3. In a project directory, run:

   cd /path/to/your/project
   kimi web

4. In the web UI, perform an action that writes data through the MCP server (e.g., remember a note).
5. Observe where the data is actually saved:
   • Expected: ~/.kimi-code/tools/<mcp>/store/workspace-<project-hash>/...
   • Actual: ~/.kimi-code/tools/<mcp>/store/workspace-<server-hash>/...

What is the expected behavior?

Expected Behavior

MCP servers spawned by kimi web should operate within the context of the project from which kimi web was launched, so that workspace-relative storage and memory behave identically to local kimi.

Actual Behavior

MCP servers spawned by kimi web operate within the Kimi CLI installation directory, causing workspace-relative storage to land in a server-level workspace and be isolated from the project.

Additional information

Environment

• OS: Windows / macOS / Linux (affected on all platforms)
• Kimi Code CLI version: observed on current kimi web behavior
• Launch mode: kimi web
• MCP server type: any server that derives workspace from process.cwd() at startup

Suggested Fixes

1. Start MCP servers from the project directory (preferred): when kimi web launches an MCP server, set the child process's cwd to the project directory rather than the server installation directory.
2. Pass the project directory explicitly: expose an environment variable (e.g., KIMI_PROJECT_DIR) or initialization parameter so MCP servers can route storage correctly without relying on process.cwd().
3. Include workspace context in every tool call: add workspaceId or projectPath to each tools/call request, allowing the server to resolve storage per request.

Additional Context

This issue is particularly problematic for MCP servers that implement persistent memory or automatic context loading. Users building such tools expect that running kimi web in a project directory behaves like running kimi in the same directory, but the workspace mismatch breaks that assumption.