Relevant source files

The following files were used as context for generating this wiki page: - [src/container_use_mcp.rs](https://github.com/RemyLoveLogicAI/zed-container-use-mcp/blob/main/src/container_use_mcp.rs) - [extension.toml](https://github.com/RemyLoveLogicAI/zed-container-use-mcp/blob/main/extension.toml) - [README.md](https://github.com/RemyLoveLogicAI/zed-container-use-mcp/blob/main/README.md) - [configuration/installation_instructions.md](https://github.com/RemyLoveLogicAI/zed-container-use-mcp/blob/main/configuration/installation_instructions.md) - [Cargo.toml](https://github.com/RemyLoveLogicAI/zed-container-use-mcp/blob/main/Cargo.toml)

# Process Management Process management within the Container Use MCP extension focuses on the discovery, configuration, and execution of the `cu` binary. This binary serves as the core Model Context Protocol (MCP) server that provides containerized environments for coding agents integrated into the Zed editor. The extension manages the lifecycle of this process by resolving its location on the host system and passing appropriate arguments for standard input/output (stdio) communication. Sources: [src/container_use_mcp.rs:1-100](), [extension.toml:1-13](), [README.md:1-10]() ## Binary Discovery and Resolution The extension implements a tiered strategy to locate the `cu` executable. It first attempts to use a user-provided path from the extension settings. If no path is provided or the provided path is invalid, it attempts to locate the binary within the system's `PATH` environment variable. ### Resolution Logic Flow The following diagram illustrates the decision-making process for locating the context server binary: ```mermaid flowchart TD Start([Start Binary Resolution]) --> CheckCache{Path in Cache?} CheckCache -- Yes --> ValidateCache[Validate File via fs::metadata] ValidateCache --> FileExists{Exists?} FileExists -- Yes --> ReturnPath[Return Path] CheckCache -- No --> SettingsCheck{Check Settings} FileExists -- No --> SettingsCheck SettingsCheck --> SettingsFound{cu_path set?} SettingsFound -- Yes --> UpdateCache[Update cached_binary_path] UpdateCache --> ReturnPath SettingsFound -- No --> SearchPath[Exec: 'which cu'] SearchPath --> PathFound{Found?} PathFound -- Yes --> UpdateCache PathFound -- No --> Error[Return Error: Failed to find cu] ``` This flow ensures that the extension can operate with zero configuration if the binary is globally installed, while still allowing for custom installations. Sources: [src/container_use_mcp.rs:24-52](), [src/container_use_mcp.rs:64-75]() ## Execution Environment Once the binary path is resolved, the extension prepares a `Command` structure for the Zed extension API. The process is executed with specific arguments to facilitate communication between Zed and the MCP server. ### Process Configuration | Element | Value / Source | Description | | :--- | :--- | :--- | | **Command** | Path to `cu` binary | The absolute path resolved during discovery. | | **Arguments** | `["stdio"]` | Instructs the `cu` binary to communicate via standard streams. | | **Environment** | Empty `vec![]` | No additional environment variables are injected by default. | | **Capabilities** | `process:exec` | The extension requires permission to execute processes. | The execution is triggered by the `context_server_command` method, which is the primary entry point for starting the server process. ```rust Ok(Command { command: self.context_server_binary_path(context_server_id)?, args: vec!["stdio".into()], env: vec![], }) ``` Sources: [src/container_use_mcp.rs:77-81](), [extension.toml:11-13]() ## Settings Integration Process management is influenced by the `ContainerUseMcpSettings` structure. This structure allows users to override the default discovery logic by specifying a custom path in the Zed `settings.json`. ### Settings Schema | Field | Type | Description | | :--- | :--- | :--- | | `cu_path` | `Option` | Optional path to the `cu` binary. If omitted, the extension searches the `PATH`. | The extension uses `zed_extension_api::settings::ContextServerSettings` to retrieve these configurations at the project level, allowing for project-specific binary overrides if necessary. Sources: [src/container_use_mcp.rs:11-14](), [src/container_use_mcp.rs:64-70](), [README.md:16-26]() ## Error Handling and Installation When process management fails (e.g., the binary cannot be found), the extension provides instructions to the user. This is managed through the `context_server_configuration` method, which includes installation guidance. ### Failure Handling Sequence ```mermaid sequenceDiagram participant Zed as Zed Editor participant Ext as Extension participant OS as Operating System Zed->>Ext: Request context_server_command Ext->>OS: Execute 'which cu' OS-->>Ext: Command failure or empty result Ext--xZed: Return Error (Failed to find cu path) Zed->>Ext: Request context_server_configuration Ext-->>Zed: Provide installation_instructions.md ``` The error message specifically directs users to the `README.md` or the provided installation instructions, which suggest building the binary from source or downloading specific rules. Sources: [src/container_use_mcp.rs:49-51](), [src/container_use_mcp.rs:85-97](), [configuration/installation_instructions.md:1-1]() ## Summary Process management in the Container Use MCP extension is a robust system for binary resolution and execution. By supporting both automated `PATH` discovery and explicit configuration, it ensures the `cu` process can be reliably started as an MCP server. The lifecycle is tightly integrated with the Zed Extension API, utilizing the `Command` and `ContextServerConfiguration` structures to maintain a seamless bridge between the editor and the containerized environment. Sources: [src/container_use_mcp.rs:1-100](), [extension.toml:1-15]() assistant

Relevant source files

# Process Management Process Management within the Container Use MCP extension governs the lifecycle, discovery, and execution of the `cu` binary. This binary acts as the core Model Context Protocol (MCP) server, facilitating containerized environments for coding agents within the Zed editor. The extension ensures that the server process is correctly located on the host system and initialized with the appropriate communication protocols. Sources: [src/container_use_mcp.rs:1-100](), [extension.toml:1-15](), [README.md:1-10]() ## Binary Discovery and Path Resolution The extension implements a structured resolution strategy to find the `cu` executable. It prioritizes user-defined configurations before falling back to system-wide searches. This logic is encapsulated within the `context_server_binary_path` method. ### Resolution Hierarchy 1. **Cached Path**: Checks if a valid path is already stored in the extension's state. 2. **Custom Settings**: Retrieves the `cu_path` from the user's Zed settings. 3. **System PATH**: Executes the `which cu` command to find the binary in the environment's path. ```mermaid flowchart TD Start([Start Binary Resolution]) --> CheckCache{Path Cached?} CheckCache -- Yes --> Validate[Validate File Exists] Validate -- Valid --> Success([Return Path]) Validate -- Invalid --> CheckSettings{Check Zed Settings} CheckCache -- No --> CheckSettings CheckSettings -- cu_path Set --> UpdateCache[Update Cache] UpdateCache --> Success CheckSettings -- No Path Set --> ExecWhich[Execute 'which cu'] ExecWhich --> Found{Binary Found?} Found -- Yes --> UpdateCache Found -- No --> Error[Throw Error: Follow README] ``` The diagram shows the logic used to determine the executable path. Sources: [src/container_use_mcp.rs:24-52](), [src/container_use_mcp.rs:64-75]() ## Server Initialization and Execution Once the path is resolved, the extension configures the process for execution via the `zed_extension_api::Command` structure. The server is designed to communicate using the Standard Input/Output (stdio) transport layer. ### Process Configuration Parameters | Parameter | Value | Description | | :--- | :--- | :--- | | **Binary Command** | Resolved `cu` path | The absolute path to the Container Use binary. | | **Arguments** | `["stdio"]` | Forces the MCP server to use stdio for communication. | | **Environment** | Empty (`vec![]`) | No specific environment variables are injected by default. | | **Capability** | `process:exec` | Requires Zed capability to execute external processes. | Sources: [src/container_use_mcp.rs:77-81](), [extension.toml:11-13]() ### Execution Logic Snippet The following implementation demonstrates how the command is constructed: ```rust // src/container_use_mcp.rs:77-81 Ok(Command { command: self.context_server_binary_path(context_server_id)?, args: vec!["stdio".into()], env: vec![], }) ``` Sources: [src/container_use_mcp.rs:77-81]() ## Configuration and Settings Integration Process management behavior can be modified through the `ContainerUseMcpSettings` data structure. This allows users to manually specify paths if the binary is installed in a non-standard location. ### Settings Data Model | Field | Type | Description | | :--- | :--- | :--- | | `cu_path` | `Option` | Optional override for the `cu` binary location. | Users can configure this in `settings.json` under the `container-use-mcp` key: ```json { "context_servers": { "container-use-mcp": { "settings": { "cu_path": "/path/to/cu" } } } } ``` Sources: [src/container_use_mcp.rs:11-14](), [README.md:16-26]() ## Error Handling and User Feedback If the process cannot be started because the binary is missing, the extension provides contextual error messages and refers to installation instructions. ### Interaction Sequence ```mermaid sequenceDiagram participant Zed as Zed Editor participant Ext as Extension API participant OS as Operating System Zed->>Ext: Request Context Server Start Ext->>OS: Process Execution (which cu) alt Binary Not Found OS-->>Ext: Error/Empty Ext-->>Zed: Return Error: "Failed to find cu path" Zed->>Ext: Get Configuration Instructions Ext-->>Zed: Show installation_instructions.md else Binary Found OS-->>Ext: Path returned Ext->>OS: Start cu process with 'stdio' OS-->>Ext: PID spawned end ``` The sequence shows the interaction between Zed, the extension, and the OS during process startup. Sources: [src/container_use_mcp.rs:49-51](), [src/container_use_mcp.rs:85-97](), [configuration/installation_instructions.md:1-1]() ## Summary Process management in the Container Use MCP extension is centered on the reliable execution of the `cu` MCP server. By utilizing a multi-step discovery process and standardized stdio communication, the extension ensures that coding agents have access to containerized environments regardless of the specific host installation path. Sources: [src/container_use_mcp.rs:1-100](), [README.md:1-35]()