Varoon Kodithala
c9a68ca71e
## Description ### Motivation File-based stdio MCP servers spawned from a project's `.mcp.json` (e.g. `pnpm run mcp:foo`, or anything using `./tooling_scripts/...`) fail with: ``` Transport creation error: No such file or directory (os error 2) ``` Root cause: when the user's `.mcp.json` doesn't include a `working_directory`, Warp's spawner inherits whatever cwd Warp was launched from rather than the directory the config was discovered in. Two failure modes share this same root cause: - **Repo-relative commands/args** (e.g. `./tooling_scripts/foo`, `node ./src/server.js`) can't be resolved from outside the repo, so `execvp` returns `ENOENT`. - **Workspace-aware launchers** like `pnpm`/`npm`/`yarn` walk up from cwd looking for `package.json` (and workspace manifests). When cwd isn't inside the repo, they bail out before launching the requested script — surfacing as `ENOENT` from the spawner's perspective. `working_directory` is a Warp/VS-Code-style extension; the canonical Anthropic/Cursor MCP schemas don't include it, so most `.mcp.json` files in the wild don't set it. ### Implementation - New helper `FileBasedMCPManager::spawn_root_for_installation(uuid)` returning the discovery root for any file-based install: the repo root for project-scoped configs, the home directory for global configs (Warp and third-party). Returns `None` for non-file-based installs (e.g. cloud-templated ones), leaving them unaffected. Global Warp installs are remapped from `~/.warp/` (Warp internal state) to `~` so all global installs share a consistent cwd. - In `TemplatableMCPServerManager::spawn_server_impl`, default `cli_server.cwd_parameter` from this helper when unset. Single funnel — covers both auto-spawn and the manual UI opt-in path. User-supplied `working_directory` always wins. - ENOENT-aware logging at the spawn site: when `TokioChildProcess::spawn()` fails with `NotFound`, the MCP log file now spells out the server name, the missing executable, the cwd we used, and a hint pointing the user at `working_directory`. The user-surfaced error string is unchanged. - Documented the new defaulting behavior and `working_directory` override in `resources/bundled/skills/add-mcp-server/SKILL.md`. ## Testing Verified spawn-site behavior manually. Demo [here](https://www.loom.com/share/ec01d98ae9114433b8ae87f5f17adfd4)! - Added `test_parse_cli_server_preserves_explicit_working_directory` in `mod_test.rs` to lock in that an explicitly-set `working_directory` round-trips through parsing and won't be clobbered by the new defaulting logic. - Skipped a unit test for the new helper itself — it's a thin lookup over `file_based_servers_by_root` and the sorted-pick policy is straightforward enough to validate manually. - Spawn-site behavior (cwd actually applied, ENOENT log emission) verified manually against a `pnpm`\-based repro. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode ## Changelog Entries for Stable CHANGELOG-BUG-FIX: Project-scoped file-based MCP servers now spawn from the repo root by default (and global ones from `~`), so configs with relative commands/args (and workspace launchers like `pnpm`/`npm`) work without an explicit `working_directory`.
Website · Code · Agents · Terminal · Drive · Docs · How Warp Works
Note
OpenAI is the founding sponsor of the new, open-source Warp repository, and the new agentic management workflows are powered by GPT models.
About
Warp is an agentic development environment, born out of the terminal. Use Warp's built-in coding agent, or bring your own CLI agent (Claude Code, Codex, Gemini CLI, and others).
Installation
You can download Warp and read our docs for platform-specific instructions.
Licensing
Warp's UI framework (the warpui_core and warpui crates) are licensed under the MIT license.
The rest of the code in this repository is licensed under the AGPL v3.
Open Source & Contributing
Warp's client codebase is open source and lives in this repository. We welcome community contributions and have designed a lightweight workflow to help new contributors get started. For the full contribution flow, read our CONTRIBUTING.md guide.
Issue to PR
Before filing, search existing issues for your bug or feature request. If nothing exists, file an issue using our templates. Security vulnerabilities should be reported privately as described in CONTRIBUTING.md.
Once filed, a Warp maintainer reviews the issue and may apply a readiness label: ready-to-spec signals the design is open for contributors to spec out, and ready-to-implement signals the design is settled and code PRs are welcome. Anyone can pick up a labeled issue — mention @oss-maintainers on an issue if you'd like it considered for a readiness label.
Building the Repo Locally
To build and run Warp from source:
./script/bootstrap # platform-specific setup
./script/run # build and run Warp
./script/presubmit # fmt, clippy, and tests
See WARP.md for the full engineering guide, including coding style, testing, and platform-specific notes.
Joining the Team
Interested in joining the team? See our open roles.
Support and Questions
- See our docs for a comprehensive guide to Warp's features.
- Join our Slack Community to connect with other users and get help from the Warp team.
- Try our Preview build to test the latest experimental features.
- Mention @oss-maintainers on any issue to escalate to the team — for example, if you encounter problems with the automated agents.
Code of Conduct
We ask everyone to be respectful and empathetic. Warp follows the Code of Conduct. To report violations, email warp-coc at warp.dev.
Open Source Dependencies
We'd like to call out a few of the open source dependencies that have helped Warp to get off the ground: