master
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Varoon Kodithala
|
bc3fffa7e5 |
[APP-4285] Send slash commands as follow-ups with active AI streams (#9243)
## Description Running `/pr-comments` (or any other slash command that targets the currently-selected conversation) while an AI response stream is in-flight crashed in debug builds. `BlocklistAIController::send_request_input` hits its in-flight invariant and fires `safe_assert!(false, ...)` (panics in debug, returns `Err` in release). The user-query path (`send_query`) avoids this because it pre-cancels any active stream on the target conversation with `CancellationReason::FollowUpSubmitted` before calling `send_request_input`. Slash commands bypass that path and dispatch directly via `SlashCommandRequest::send_request`, so the cancel never happens. This PR makes `send_slash_command_request` mirror that cancel-and-resend: if the target conversation has an in-flight stream, cancel it before dispatching. All `SlashCommandRequest` variants are conceptually a fresh user turn (a follow-up), so this matches the semantics users already get from typing a follow-up message. `send_queued_slash_command_request` is unchanged — it's only invoked from `Input::submit_queued_prompt` once the conversation is idle, so no pre-cancel is needed. ## Testing Verified locally. Demo [here](https://www.loom.com/share/a9638ac9a53b48349ce21d03eaba516a)! - Manually reproduced the crash on a dogfood debug build by triggering `/pr-comments` mid-stream; confirmed the panic at the `safe_assert!` in `BlocklistAIController::send_request_input`. - After the fix: same repro cancels the in-flight turn and dispatches `/pr-comments` cleanly. Same behavior verified for `/skills` (InvokeSkill), `/compact` (Summarize), and `/create-environment`. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode ## Changelog Entries for Stable CHANGELOG-BUG-FIX: Fixed an issue where slash commands sent while an agent was still responding were silently dropped. Now, slash commands like `/pr-comments` run as follow-ups, just like typed messages. --- Run: https://staging.warp.dev/conversation/aeecfa2d-1456-440b-9961-c27295d82531 Plan: https://staging.warp.dev/drive/notebook/Ryj2w6xDSqDwNJYhpwwI0Vly |
||
|
Varoon Kodithala
|
c9a68ca71e |
[APP-4249] Set default cwd for project-scoped MCP servers (#9239)
## 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`. |