## Summary
Fixes task variable resolution and Windows shell argument handling when
`$ZED_WORKTREE_ROOT` contains spaces or when tasks are spawned while the
global `tasks.json` buffer is focused.
## Problem
`$ZED_WORKTREE_ROOT` could resolve from the active editor item even when
that item was outside every visible project worktree, such as the global
`tasks.json` file under the Zed config directory. On Windows, paths with
spaces also need to remain one logical argument when terminal shell
commands are constructed.
## Changes
- Only let the active editor item provide the active task context when
it belongs to a visible project worktree.
- Fall back to the selected or first visible project worktree when the
active editor item is external/global.
- Preserve project-file-specific task variables for normal project
buffers.
- Add regression coverage for `$ZED_WORKTREE_ROOT` in `args` and `cwd`
with synthetic Windows-style paths containing spaces.
- Add regression coverage for PowerShell and cmd shell command
construction so a spaced path remains quoted as one shell argument.
## Testing
Ran on Windows with Rust 1.95.0, Visual Studio Build Tools 2022, and
Windows SDK 10.0.26100.0:
- `cargo fmt --all --check`
- `cargo test -p util
shell_builder::test::windows_powershell_preserves_spaced_arg_as_single_shell_argument
-- --exact`
- `cargo test -p util
shell_builder::test::windows_cmd_preserves_spaced_arg_as_single_shell_argument
-- --exact`
- `cargo test -p task
task_template::tests::test_worktree_root_with_spaces_stays_atomic_in_args_and_cwd
-- --exact`
- `cargo test -p tasks_ui
tests::test_non_project_active_editor_uses_visible_worktree_context --
--exact`
- `cargo test -p task`
- `cargo test -p tasks_ui`
- `cargo test -p workspace`
Release Notes:
- Fix Windows task path handling for worktree variables with spaces
- [GPUI] N/A
Co-authored-by: Chris Biscardi <chris@christopherbiscardi.com>
## Summary
Fix agent message hyperlinks that point to Windows file paths but are
not parsed as openable project paths.
This covers links like:
```md
[Cargo.toml](</C:/Projects/Example Workspace/Cargo.toml:2>)
[filename.ext](C:\Projects\Example%20Workspace\path\to\filename.ext:42)
[AGENTS.md](</c/Projects/Example Workspace/AGENTS.md>)
```
## Problem
Agent responses can emit Markdown hyperlinks whose targets are Windows
paths rather than `file://` URLs. Some of those targets include a
leading slash before the drive (`/C:/...`), Git Bash/MSYS-style drive
prefixes (`/c/...`), percent-escaped spaces, or line suffixes. These
were not normalized before mention parsing, so clicking the hyperlink
could do nothing instead of opening the file.
## Solution
- Normalize hyperlink path targets before parsing them as `MentionUri`
paths.
- Decode percent escapes in bare path targets so `%20` becomes a literal
space before path/line parsing.
- Convert Windows-compatible hyperlink paths such as `/C:/...` and
`/c/...` into native Windows paths.
- Generate file resource links from `find_path_tool` through
`MentionUri::to_uri()` instead of hand-building `file://` strings.
## Result
Before: clicking agent path hyperlinks did not open the referenced file.
After:
https://github.com/user-attachments/assets/6c7fad77-4a1e-4497-a4f9-4a4fdf86d527
## Validation
- `cargo test -p acp_thread test_parse_windows --features test-support`
- `cargo fmt --check`
## Follow-up changes
Additions on top of the original work above:
- Moved the hyperlink heuristics into a dedicated
`MentionUri::parse_hyperlink` entry point. `MentionUri::parse` stays
strict, so canonical mention URIs round-trip verbatim and other callers
(message editor, thread deserialization, resource links) are unaffected.
- Percent escapes that decode to path separators (`%2F`, `%5C`) are left
encoded, so decoding can never change which directories a path
traverses.
- Bare paths with escapes are ambiguous (a file may literally be named
`a%20b.rs`): `open_link` prefers the decoded interpretation and falls
back to `MentionUri::parse_hyperlink_literal` when the decoded path
doesn't resolve in the project but the literal one does.
- Links to files outside the project's worktrees now open, gated by an
async existence check through the project `Fs` (correct for remote
projects; broken links no longer create empty buffers or add worktrees).
`open_link` and the mention-crease open path are unified into one
`open_abs_path_at_point`, which now also places the cursor for
out-of-project selection/symbol links.
- `grep_tool` resource links also go through `MentionUri::to_uri()` now,
fixing malformed `file://C:\...` URIs and unencoded spaces.
- Added tests: percent-escape disambiguation, out-of-project link
opening, drive-letter normalization, UNC paths, and literal-path parsing
(`cargo test -p acp_thread mention`, `cargo test -p agent_ui open_link`,
`cargo test -p agent grep_tool`); manually verified the link spellings
above on Windows.
Release Notes:
- Fixed agent path hyperlinks on Windows when paths contain spaces or
shell-style drive prefixes.
---------
Co-authored-by: Martin Ye <martin@zed.dev>
## Summary
- Fixed the terminal inline assist tab bar tooltip so it resolves the
keybinding from the active terminal view.
- The bug happened when the initial terminal was closed and a new
terminal was opened: the tab bar button kept a cached focus handle for
the old terminal, so tooltip keybinding lookup could no longer find the
terminal key context.
- The button is now created while rendering the tab bar with the current
terminal view's focus handle, avoiding stale focus handles as terminals
are closed and recreated.
## Validation
- `cargo fmt --package terminal_view --check`
- `cargo check -p terminal_view --message-format short`
Release Notes:
- Fixed the terminal inline assist toolbar tooltip not showing its
keybinding after reopening terminals.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
