Right-clicking a ref label (branch, remote ref, or tag) in the git graph
now opens a ref-specific context menu that resolves custom git commands
with the clicked ref exposed as ZED_GIT_REF, mirroring how VS Code's git
graph offers ref-aware actions. Right-clicking elsewhere on a commit
keeps the existing commit-scoped menu.
<img width="875" height="525" alt="zed (Ubuntu) 2026_06_07 23_26_35"
src="https://github.com/user-attachments/assets/140bdcdf-6536-4b5e-ac2f-9df84f744477"
/>
releated: #55844#56354
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added a context menu for ref labels in the git graph that runs custom
git commands with the clicked ref available as `$ZED_GIT_REF`.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
This PR adds support to create custom git task that are triggered from
the git graph context menu. Both Sublime Merge and Fork have custom
command support, and I use custom commands I've built out frequently to
speed up some of my tasks at Zed. Thus, I'd like to have support in
Zed's git graph so I can use Zed even more!
It offers initial support for the following env variables:
- `ZED_GIT_SHA`
- `ZED_GIT_SHA_SHORT`
- `ZED_GIT_REPOSITORY_NAME`
- `ZED_GIT_REPOSITORY_PATH`
These are only populated in the git graph context.
This PR also introduces a the `git-command` tag, which is needed so the
git graph can filter down to these custom git commands, and so other
tasks aren't polluting the context menu.
An example would be (in the global `tasks.json`):
```json
{
"label": "Branches containing commit: $ZED_GIT_SHA_SHORT",
"command": "git",
"args": ["branch", "-a", "--contains", "$ZED_GIT_SHA"],
"tags": ["git-command"],
},
```
And then in the context menu:
<img width="646" height="296" alt="SCR-20260511-mnfa"
src="https://github.com/user-attachments/assets/0e7b811b-f47d-4a2f-9270-99e392c38663"
/>
And the output in the terminal:
<img width="585" height="184" alt="SCR-20260511-mnks"
src="https://github.com/user-attachments/assets/54d7d205-6212-4eff-8dbb-c8e908996747"
/>
The awesome thing about using tasks is we get all the task
infrastructure for free, such as history!
<img width="591" height="292" alt="SCR-20260511-mnud"
src="https://github.com/user-attachments/assets/6315be8f-dd33-470f-bfcd-aa56d7fbfdce"
/>
<img width="602" height="173" alt="SCR-20260511-moch"
src="https://github.com/user-attachments/assets/b528422c-efcc-4a7d-9783-73d945e9665b"
/>
And we have all the task configuration options too out of the box.
---
Right now, this only works with global tasks. It isn't clear how to shoe
in support for worktree-specific tasks (`.zed/tasks.json`) in a clear
way, as not all invocations of the git graph are in an area that has a
clear worktree id, and so we sort of have to guess or fallback to
something else. That can be a followup once it's more clear how we
should cover that. Or maybe someone else has a better solution.
I chose to only ship with these 4 git-specific variables for now. The
git graph also currently ONLY resolve those variables. We can adjust /
add in more in follow up PRs.
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [X] Unsafe blocks (if any) have justifying comments
- [X] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [X] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
Release Notes:
- Added support for running global custom Git command tasks from the Git
Graph commit context menu.
### Summary
This PR starts work on adding basic hook support in the `TaskStore`. To
enable users to setup tasks that are ran when the agent panel creates a
new git worktree to start a thread in. It also adds a new task variable
called `ZED_MAIN_GIT_WORKTREE` that's the absolute path to the main repo
that the newly created linked worktree is based off of.
### Follow Ups
- Get this hook working with the git worktree picker as well
- Make a more general approach to the hook system in `TaskStore`
- Add `ZED_PORT_{1..10}` task variables
- Migrate the task context creation code from `task_ui` to the basic
context provider
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Save edited buffers before running a task
Introduces a new task field for configuring which buffers are saved. For
now, this defaults to saving all buffers, but in the future we could
have a global task template to configure this setting for dynamically
created tasks.
Needed for #10251.
Release Notes:
- Edited buffers are now saved before running a task. This can be
configured with the new "save" field in `tasks.json`.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Closes#12628
Adds a `$ZED_LANGUAGE` task variable that resolves to the language name
of the active buffer (e.g., "Rust", "Python", "Shell Script"). This lets
tasks adapt behavior based on language without parsing file extensions.
Use cases from the issue:
- Pass syntax highlighting language to external tools (e.g., `rg --type
$ZED_LANGUAGE`)
- Adjust comment wrapping width per language
- Handle extensionless files and untitled buffers that have a language
assigned
VS Code provides equivalent functionality via
`${command:activeEditorLanguageId}`. Neovim exposes it as `&filetype`.
## Changes
- Added `Language` variant to `VariableName` in
`crates/task/src/task.rs`
- Populated from `buffer.language().name()` in
`BasicContextProvider::build_context`
(`crates/project/src/task_inventory.rs`), following the same pattern as
`File` and `Stem`
- Updated test fixtures in `crates/tasks_ui/src/tasks_ui.rs` to include
the new variable
- Added `ZED_LANGUAGE` to the variable list in `docs/src/tasks.md`
## Testing
Updated the existing `test_task_variables` test in `tasks_ui` to verify
`ZED_LANGUAGE` resolves to "Rust" and "TypeScript" for the respective
test buffers.
This contribution was developed with AI assistance (Claude Code).
Release Notes:
- Added `$ZED_LANGUAGE` task variable that exposes the current buffer's
language name
---------
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
## Summary
This PR extends the `always_allow` tool permission patterns to work with
Nushell, Elvish, and Rc shells. Previously, these shells were
incorrectly excluded because they don't use `&&`/`||` operators for
command chaining. However, brush-parser can safely parse their command
syntax since they all use `;` for sequential execution.
## Changes
- Add `ShellKind::Nushell`, `ShellKind::Elvish`, and `ShellKind::Rc` to
`supports_posix_chaining()`
- Split `ShellKind::Unknown` into `ShellKind::UnknownWindows` and
`ShellKind::UnknownUnix` to preserve platform-specific fallback behavior
while still denying `always_allow` patterns for unrecognized shells
- Add comprehensive tests for the new shell support
- Clarify documentation about shell compatibility
## Shell Notes
- **Nushell**: Uses `;` for sequential execution. The `and`/`or`
keywords are boolean operators on values, not command chaining.
- **Elvish**: Uses `;` to separate pipelines. Does not have `&&` or `||`
operators. Its `and`/`or` are special commands operating on values.
- **Rc (Plan 9)**: Uses `;` for sequential execution and `|` for piping.
Does not have `&&`/`||` operators.
## Security
Unknown shells still return `false` from `supports_posix_chaining()`, so
`always_allow` patterns are denied for safety when we can't verify the
shell's syntax.
(No release notes because granular tool permissions are still
feature-flagged.)
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Closes#33286
This PR adds support for Zed's `$ZED_PICK_PID` command in debug
configurations, which allows users to select a process to attach to at
debug time. When this variable is present in a debug configuration, Zed
automatically opens a process picker modal.
Follow up for this will be integrating this variable in the task system
instead of just the debug configuration system.
Release Notes:
- Added `$ZED_PICK_PID` variable for debug configurations, allowing
users to select which process to attach the debugger to at runtime
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Using `shlex` unconditionally is dangerous as it assumes the underlying
shell is POSIX which is not the case for PowerShell, CMD, or Nushell.
Therefore, whenever we want to quote the args we should utilise our
helper `util::shell::ShellKind::try_quote` which takes into account
which shell is being used to actually exec/spawn the invocation.
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Closes#39216
Note that this affects all platforms, I'm just using the prefix to make
auto-cherry-picking easier.
Release Notes:
- Fixed shell commands run by agents failing to find installed programs
in some cases.
A couple of caveats:
- We should not auto-escape arguments with Alacritty's `escape_args`
option if using CMD otherwise, the generated command will have way too
many escaped characters for CMD to parse correctly.
- When composing a full command for CMD, we need to put it in double
quotes manually: `cmd /C "activate.bat& pwsh.exe -C do_something"` so
that CMD executes the entire string as a sequence of commands.
- CMD requires `&` as a chaining operator for commands (`;` for other
shells).
Release Notes:
- N/A
When sourcing the project environment for the terminal tool, we will now
do so by spawning the shell specified by the users `terminal.shell`
setting (or as usual fall back to the login shell).
Closes#37687
Release Notes:
- N/A
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
There were a couple of things preventing this from working:
- our hack to stop the node REPL from appearing broke in recent versions
of the JS DAP that started passing `--experimental-network-inspection`
by default
- we had lost the ability to create a debug terminal without specifying
a program
This PR fixes those issues. We also fixed environment variables from the
**runInTerminal** request not getting passed to the spawned program.
Release Notes:
- Debugger: Fix RunInTerminal not working for JavaScript debugger.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
- **task: Start refactoring shell builder**
- **Unify Windows implementation of shell builder so that it's treated
like any other kind of a "custom" shell.**
- **Rename task/lib.rs to task/task.rs**
Release Notes:
- N/A
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Konstantinos St