Feature Request: Add configurable working directory for local Context Servers

[ikkurthis1998]

Problem Statement

Currently, when Zed launches a custom context server (MCP) configured via settings.json, it always uses the project's root directory as the working directory for the server process. This limitation becomes apparent and problematic when developing or running multiple local MCP servers that reside in different subdirectories within a single project.

For example, in a monorepo setup, you might have:

• my-project/mcp-server-one/
• my-project/mcp-server-two/
• my-project/backend-service/ (which might also contain an MCP)

If mcp-server-one or mcp-server-two have their own internal dependencies, configuration files, or relative paths they expect to resolve from their own subdirectory, they will fail to function correctly when launched from the project root. This forces developers to:

• Manually change directories within their MCP command arguments (e.g., cd mcp-server-one && ./server).
• Use more complex wrapper scripts to manage the working directory for each server.
• Restructure their projects to place all MCPs at the root, which might not be ideal for their overall architecture.

This significantly hinders the ability to efficiently develop and test multiple, isolated MCPs locally within a unified Zed project, making the local development and iteration cycle more cumbersome than necessary.

Solution Proposal

I propose adding an optional working_directory field to the ContextServerCommand configuration within settings.json. This new field would allow users to explicitly define the working directory from which a context server command is executed.

Here's how it would function:

• Explicit Configuration: Users could specify an absolute or relative path for working_directory (e.g., "working_directory": "mcp-server-one" or "working_directory": "/absolute/path/to/server") directly within their context_servers entry in settings.json.
• Relative Path Resolution: If a relative path is provided (e.g., "mcp-server-one"), it would be resolved relative to the project's root directory. This is crucial for seamless monorepo integration.
• Default Behavior Preservation: If the working_directory field is omitted, the context server would continue to launch from the project's root directory, ensuring backward compatibility and no change for existing setups.
• Benefits for Local MCP Development: This enhancement would greatly simplify the local development and testing of multiple context servers in a monorepo or multi-package project by allowing each MCP to be launched from its correct internal directory without manual intervention or complex scripting. It aligns Zed more closely with modern development practices for modular applications.

I've already implemented a proof-of-concept for this functionality, which involves changes in the following files:

• /crates/agent_ui/src/agent_configuration/configure_context_server_modal.rs
• /crates/context_server/src/context_server.rs
• /crates/project/src/context_server_store.rs
• /crates/project/src/context_server_store/extension.rs
• /crates/project/src/project_settings.rs

This change is designed to be additive and non-breaking, providing a crucial configuration option for developers working with distributed or modular context server architectures.

[ikkurthis1998]

Example Usage