`Thread::cumulative_token_usage` has been dead code since the agent2
rewrite: the field was added as a persistence placeholder in #36483 with
`#[allow(unused)]`, and the accumulation logic was deleted along with
agent1 in #40495. Since then, every saved thread persists
`cumulative_token_usage` as `{}` in `threads.db`, breaking offline
token-usage analysis and silently degrading eval reporting (`eval_cli`
prefers this value and was always falling back to the last request's
snapshot, undercounting multi-step turns).
This PR restores the accumulation, mirroring the original agent1
implementation:
- Providers emit multiple cumulative-per-request `UsageUpdate` snapshots
during a single request, so naive `+=` would double-count. We track the
previous snapshot for the in-flight request
(`current_request_token_usage`) and accumulate only the delta, resetting
the tracker each time a new completion request is built in
`run_turn_internal`. This counts each request exactly once, including
tool-call rounds and retries within a turn.
- Unlike agent1, the delta uses per-field `saturating_sub` instead of
the panicking `Sub` impl, so a provider reporting a smaller snapshot
can't crash Zed.
- Removed the `#[allow(unused)]`; the value now round-trips through
`to_db`/`from_db`, surviving restarts and continuing to grow when a
thread is reopened.
- Added a `cumulative_token_usage()` accessor following the
`latest_request_token_usage` convention.
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:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
The parser stores emitted byte offsets between partial tool-call parses.
Because partial JSON can be repaired differently as more bytes arrive, a
byte offset that was valid in an earlier string can land inside a
multibyte character in a later string. We now normalize those offsets
with `find_char_boundary` before slicing.
Added property tests covering boundary-sensitive write/edit streaming
sequences to prevent regressions.
Fixes Sentry ZED-8Y1 / 7523469866.
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:
- Fixed a crash that could occur while streaming agent edits containing
multibyte characters.
Closes AI-286
This PR adds a right-click menu to thread items in the sidebar. A big
motivation for this addition was surfacing the "regenerate thread title"
action. And because this action and the "open thread as markdown" action
previously only worked on the already-loaded agent panel, there was a
load of plumbing needed to make that work even for threads in workspaces
that haven't been loaded, mostly using the thread metadata store. At the
end of the day, the title regeneration feature is only possible for the
Zed agent, so this is gated from external agents. But I believe it's now
in a slightly nicer spot due to some refactors to better expose the
state in which the title regeneration can fall into.
Release Notes:
- Agent: Added a right-click menu to thread items in the sidebar,
allowing to regenerate a thread title, rename a thread title, open the
thread as markdown, and archive it.
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Follow-up hardening on top of #57972 (granular sandbox write
permissions), based on a review of that branch. The most important fix
is that model-requested `fs_write_paths` were joined but never
normalized, so a path containing `..` could pass the lexical
subtree-containment checks while seatbelt canonicalized it to somewhere
else entirely — causing skipped approval prompts and silent runtime
write denials. Write paths are now lexically normalized (via
`util::paths::normalize_lexically`) at the point they enter the system,
both for model requests and for hand-edited persistent grants, so the
containment check, the approval prompt, and the enforced sandbox policy
all operate on the same path.
The subtree insert/prune and containment logic had drifted into roughly
five near-identical copies across `agent`, `agent_settings`, and
`settings_content`; these now share `util::paths::insert_subtree` and
`path_within_subtree`. The dead `SandboxPermissions::covers` (only ever
exercised by its own tests, duplicating the production
`covers_with_persistent`) is removed, and its tests rewritten to cover
the real settings-compilation path including `..` normalization.
The remaining changes reduce brittleness: the sandbox permission option
ids (`allow`, `allow_thread`, `allow_always`, `deny`) are now shared
constants in `acp_thread` instead of bare string literals scattered
across the agent and UI, `persist_sandbox_always_permission` logs
instead of silently doing nothing when no filesystem is available, and a
comment documents why replay always resolves the terminal tool to the
non-sandboxed variant.
Release Notes:
- N/A
---------
Co-authored-by: Martin Ye <martin@zed.dev>
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Brings stable logout and additional directories support as well as
removing dep on rmcp + tokio
This also removed the unstable model selector (replaced awhile ago by
session config options) so it removes all of that code.
Native agent still uses it because we have a special model selector that
would need more work to rip out
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:
- N/A
Adds granular, per-path write permissions to the agent's sandboxed
`terminal` tool.
Previously a command could only request unrestricted filesystem writes
(`allow_fs_write: true`) as an all-or-nothing escape hatch. Now the
model can request write access to specific paths via `fs_write_paths`,
and each granted directory covers its whole subtree. The broad escape
hatch is still available as `allow_fs_write_all: true` for cases where
the paths can't be enumerated up front.
Approval prompts now let the user grant a write request either just for
that command or for the rest of the conversation. Conversation grants
are tracked in memory (never persisted) using pure subtree containment,
so later commands writing under an already-granted path run without
prompting again.
Closes AI-335
Release Notes:
- Improved the agent's terminal sandbox so commands can request write
access to specific paths instead of all-or-nothing filesystem access,
with the option to grant access for a single command or the rest of the
conversation.
---------
Co-authored-by: Anant Goel <anantdgoel@gmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Adds two built-in agent tools, behind the staff-only
`create-thread-tool` feature flag, that let the agent spawn independent
sibling threads:
- **`create_thread`** creates a new thread with a title and initial
prompt. It runs on the user's behalf and shows up in the agent sidebar
like a thread the user started themselves, but it runs in the background
— the active thread is never interrupted — and it does **not** report
results back to the caller. (Use `spawn_agent` when you want the
results.)
- **`list_agents_and_models`** enumerates the configured agents and, for
the native agent, the available models, so the agent can pick a
cheaper/faster model for bulk work. The motivating stress test was
"spawn 100 threads that each write a haiku, using Haiku instead of
Opus."
By default the sibling shares the parent's project and worktree. If
`use_new_worktree` is set, `create_thread` instead opens a new
background workspace backed by fresh linked git worktrees of the
project's repos — the same flow you get from the worktree picker's
"Create worktree" — and starts the thread there. The new workspace opens
as a background tab so it doesn't pull you away from what you're doing.
A few notes on the design:
- The `agent` crate can't depend on the UI, so there's a
`SiblingThreadHost` trait that `agent_ui::AgentPanel` implements and
installs on the `NativeAgent`. Tool calls in a native-agent thread route
through it.
- Sibling threads go through the same `create_agent_thread` →
`ConversationView` path as the user-facing "new thread" action, so
eviction, persistence, and sidebar rendering match user-created threads.
- An explicit `agent`/`model` override doesn't clobber the panel's
selected agent or the last-used-agent preference — those are snapshotted
and restored around the call.
- The worktree path reuses the existing "Create worktree" machinery
rather than reimplementing it; the agent flow just opens the new
workspace in the background instead of activating it.
A couple of things I left out or want to call out:
- There's no tool to operate on an already-created sibling by session
id. The success payload deliberately omits it, since the session is
populated asynchronously and nothing consumes it yet.
- When a project has multiple worktrees that are linked worktrees of the
*same* underlying repo, they collapse into a single new worktree (they
resolve to the same target path). The tool returns a warning in that
case rather than failing — and this also fixes a latent collision the
manual "Create worktree" flow would hit in the same situation.
Release Notes:
- N/A
Removes the feature flag around terminal output selection so the
terminal tool always exposes head_lines and tail_lines. This keeps the
simpler behavior from the landed implementation while avoiding a
separate rollout path for the tool schema.
Release Notes:
- Improved agent terminal output controls by making them available
without a feature flag
Adds optional terminal tool parameters that let agents receive only the
first lines, last lines, or both from a command's final output while
leaving the live terminal output visible to users. This is gated by the
terminal-tail feature flag and updates the tool descriptions to steer
agents away from piping through head, tail, or similar filters.
Closes AI-36
Release Notes:
- Let agents use the terminal tool with builtin "head/tail" so they
don't have to pipe to head/tail and lose incremental output
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
Closes#58088
Release Notes:
- Allows for symlinked global skill directories
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Co-authored-by: Martin Ye <martin@zed.dev>
Agent request construction now honors persisted compaction markers by
rebuilding the model-visible window from the latest boundary, retaining
recent user context for summary compactions, and treating
provider-native compactions as suffix-only until native replay lands.
Release Notes:
- N/A
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
[PR #57878](https://github.com/zed-industries/zed/pull/57878) introduced
a per-thread sandboxing temp directory that, for every terminal command,
overrode `TMPDIR`/`TMP`/`TEMP` and pushed the directory into the sandbox
writable scope. For remote projects this temp directory is created on
the client while the terminal actually runs on the remote host, so it
leaked client-side environment variables into the remote terminal and
pointed `$TMPDIR` at a path that doesn't exist there.
This gates the temp-directory logic behind `project.is_local()`, so
remote projects no longer get their terminal environment infected. This
doesn't restore the per-thread tempdir behavior for remoting, but it
undoes the regression.
Closes AI-348
Release Notes:
- Fixed remote terminals having their environment overridden by
client-side temp directory variables
Adds the flat context compaction marker data model and replays persisted
markers into native agent transcripts as static dividers. This lets
compacted thread boundaries deserialize, render, and export to Markdown
without enabling automatic compaction behavior yet.
Release Notes:
- Improved agent threads to show restored context compaction dividers in
conversations
Project-local skills now load through project buffers so remote
workspaces can resolve them consistently with other project files.
Validation:
- cargo check -p agent_skills -p agent
- cargo test -p agent_skills
- cargo test -p agent skills
Closes AI-329
Closes https://github.com/zed-industries/zed/issues/57877
Release Notes:
- Improved project skills support in remote workspaces.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
There's currently no way to customize AI-generated commit messages on a
per-commit basis. You can put instructions in AGENTS.md or a project
rules file, but those get fed into every agent interaction, not just
commit generation. The built-in "Commit message" prompt used to be
editable in the Rules Library, but that was replaced by Skills, which
aren't used when generating commit messages.
This PR adds an `agent.commit_message_instructions` setting. Its
contents are added to the commit message prompt in their own section,
alongside any project rules, so you can ask for a specific format
(Conventional Commits, a ticket prefix, etc.) without changing how the
agent behaves elsewhere:
```json
{
"agent": {
"commit_message_instructions": "Use the Conventional Commits format: <type>(<scope>): <description>."
}
}
```
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
Addresses #26503
Release Notes:
- Added an `agent.commit_message_instructions` setting to customize
AI-generated git commit messages.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
## Summary
While profiling agent sessions that make a lot of `edit_file`
operations, I noticed the LSP `textDocument/didChange` handler firing
excessively. Looking into this, I found out that the streaming edit
pipeline was applying each `CharOperation` from `StreamingDiff` as its
own `buffer.edit` transaction, and every transaction emits a
`BufferEvent::Edited` event. Each event can trigger several other
expensive events depending on whether the buffer is being rendered in an
editor or is registered with a language.
For example, there are `didChange` LSP events, the editor's on edit work
(matching brackets, bracket colorization, code actions, outline), and
more. A single `edit_file` could trigger hundreds of these at the higher
end in a single synchronous app update, which would block the foreground
thread for a bit and cause Zed to drop frames.
I fixed this by collecting all of a chunk's `CharOperation`s and
applying them in one `buffer.edit` call, so only a single
`BufferEvent::Edited` event gets emitted. This is safe because
operations are non overlapping by design of streaming diff (the edit
cursor only advances).
## Why this wasn't caught earlier
The cost only fully appears when a buffer is both registered with a
language server and rendered in an editor. Without that, most of the per
transaction observers never run, so the existing `edit_file_tool`
benchmark (which ran the tool against a bare buffer) didn't surface it.
I reworked the benchmark to open the edited buffer in an editor view,
register a fake language server with per edit diagnostics, and lay out a
frame, so it exercises the same cascade as the real editor. I also added
a larger fixture.
## Results
Measured with the `release-fast` profile on the reworked benchmark:
| Fixture | Initial file | Before | After | Improvement |
| --- | --- | --- | --- | --- |
| `tiny_function_rewrite` | 1.4 KB | 31.1 ms | 12.1 ms | −61% |
| `small_function_rewrite` | 3.0 KB | 42.4 ms | 19.3 ms | −55% |
| `medium_many_small_changes` | 4.6 KB | 309.2 ms | 151.5 ms | −51% |
| `medium_insertions` | 4.6 KB | 171.8 ms | 126.1 ms | −27% |
| `large_multi_edit` | 44 KB | 9,549 ms | 919 ms | −90% |
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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Improved agent's edit file tool performance
## Summary
This started from #57636, after we saw ChatGPT subscription/Codex
requests stall over the past week. OpenCode v1.15.11 shipped related
resilience fixes for the same class of Codex subscription endpoint
issues, so this ports the relevant pieces into Zed's native ChatGPT
subscription provider.
When Zed asks ChatGPT/Codex for a response, sometimes the server
connection can get stuck before it even sends the first response
headers. Before this PR, Zed could wait indefinitely, which looks like
OpenCode/Zed “stalling.”
This PR makes Zed:
- Wait up to 10 seconds for the server to start responding.
- If nothing comes back in that window, treat it as a temporary
network/API failure.
- Let the existing retry logic try again instead of leaving the user
stuck.
- Send a stable session-id header so OpenAI’s Codex backend can
associate requests with the same Zed agent thread.
- Add tests to make sure:
- stuck-before-response requests time out,
- normal slow streaming responses are not cut off,
- ChatGPT subscription requests send the right session header,
- the agent retries this kind of failure.
intended user-facing result is: fewer “the assistant is just sitting
there forever” failures when using ChatGPT subscription models.
## Verification
- cargo test -p open_ai responses
- cargo test -p language_models openai_subscribed
- cargo test -p agent test_send_retry_on_http_send_error
- cargo check -p open_ai
- cargo check -p language_models
- cargo check -p agent
Release Notes:
- Fixed ChatGPT subscription requests stalling indefinitely before
response headers arrive.
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
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Stacked on top of #57430.
When the `sandboxing` feature flag is on (macOS only), agent-run
terminal commands are launched under `/usr/bin/sandbox-exec` with a
per-command Seatbelt policy:
- **Reads:** any path on the filesystem.
- **Writes:** each project worktree plus a per-command `$TMPDIR`.
- **Network:** blocked.
The model can request relaxations on individual calls via three new
input flags on the `terminal` tool:
- `allow_network: true`
- `allow_fs_write: true`
- `unsandboxed: true`
Each one triggers a separate always-prompt user approval (bypassing any
`always_allow` rules, since escalation is a stronger trust boundary than
the baseline command approval). The flags are silently ignored when
sandboxing is off, so the model can't surreptitiously change runtime
behavior by setting them in the no-op case.
The per-command tempdir is provisioned regardless of sandbox state so
the model can't infer whether the sandbox is in effect by looking at
`$TMPDIR`.
The Seatbelt config file's lifetime is tied to the `Terminal` entity via
an opaque RAII handle (`SandboxConfigHandle = Box<dyn Any + Send>`), so
cancellation paths drop it automatically.
### Notes for review
- The writable scope passed to the sandbox is the project's worktree
paths plus the per-command tempdir, **not** the resolved `cd` working
directory — `cd` is model-controlled, and using it as the writable scope
would let the model widen its own write permissions outside the project.
- The new tool flags are always present in the JSON schema (with
`#[serde(default)]`), even when the sandbox prompt section isn't
rendered. The system prompt only documents them when the section is
present, so the model shouldn't try to use them when it's not — but the
schema doesn't actively reject them, just ignores them.
- I opted not to add an end-to-end test for the escalation prompt path:
the existing `FakeThreadEnvironment` ignores the new params and toggling
the feature flag in tests is more wiring than felt worth it for a first
cut. The pure-function pieces (`sandbox_approval_title`, schema,
deserialization) are covered, and the sandbox crate itself has
end-to-end tests that actually invoke `sandbox-exec`.
Release Notes:
- N/A
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Stacked on top of #57429.
Adds a new `sandboxing` feature flag (off for staff by default) and a
single source-of-truth helper `sandboxing_enabled(cx) = cfg!(target_os =
"macos") && cx.has_flag::<SandboxingFeatureFlag>()`. When the helper
returns true, the agent's system prompt gains a new `## Terminal
sandbox` section that:
- Lists each worktree's absolute path as a writable directory.
- Describes the per-command `$TMPDIR` scratch directory.
- States that outbound network access is blocked.
- Documents the three per-command flags (`allow_network`,
`allow_fs_write`, `unsandboxed`) the model can request to relax the
sandbox.
- Tells the model the section is stable for the duration of the
conversation.
When the flag is off, the section is omitted entirely — no mention of
sandboxing at all.
No behavior change to terminal execution yet; that's the next PR in the
stack.
Three new tests cover: section omitted when `sandboxing: false`, section
rendered with all worktrees + flag docs when `sandboxing: true`, and the
zero-worktrees case.
Release Notes:
- N/A
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Co-authored-by: Martin Ye <martin@zed.dev>
Release Notes:
- agent: Fixed an issue where commit message generation would not
respect instructions from global `AGENTS.md`
---------
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Extends the same `~/.agents/skills` special case that
`create_directory`, `edit_file`, and `write_file` already use to the
path tools, so the agent can copy or move skills into and out of the
global skills folder and delete individual skills or skill resources
beneath it.
- `copy_path` now allows source and/or destination to be a descendant of
`~/.agents/skills`, going through `fs::copy_recursive` directly when one
side is outside the project.
- `move_path` now allows source and/or destination to be a descendant of
`~/.agents/skills`, going through `fs.rename` directly when one side is
outside the project. Moving the `~/.agents/skills` root itself is
rejected.
- `delete_path` now allows deleting any file or directory beneath
`~/.agents/skills`, going through `fs.remove_dir` / `fs.remove_file`
directly. Deleting the `~/.agents/skills` root itself is rejected.
- All three tools still always prompt for approval on agent-skill paths,
even when default tool permissions are set to allow.
- Added shared helpers in `tool_permissions.rs` for resolving global
skill descendants and rejecting operations on the skills root where
needed.
- Added tests covering copying and moving skills in both directions,
deleting a global skill directory/file, and rejecting deletion of the
skills root.
Release Notes:
- Agent can now copy or move skills into and out of `~/.agents/skills`
and delete individual skills, with an explicit confirmation prompt for
each operation
Summary
- Allow write_file and edit_file to create or modify files under
~/.agents/skills.
- Keep the global skills exception constrained to that directory and
preserve existing project-path behavior.
- Document global skill file editing support in the built-in
create-skill instructions.
Tests
- cargo fmt -p agent
- cargo test -p agent global_skill_file
- cargo test -p agent
test_create_directory_allows_global_skill_directory
Release Notes:
- Fixed agent file editing for global skills
---------
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Ensures that we show the error message of the `edit_file`/`write_file`
tools in the UI
Release Notes:
- agent: Fixed an issue where errors would not show up in the UI if an
edit tool call failed
For long threads we will spend more and more time cloning the messages
just to save them to the database, as we need a copy of everything to do
so asynchronously. Messages are really expensive to clone though and we
accumulate a lot of them really fast, so even for smaller threads we
start seeing pauses in the millisecond range. The fix to this is fairly
simple though, we never mutate the messages once pushed to the vec, so
just Arc them.
This PR also slightly changes `UserMessage` to be a bit faster to clone
as well.
Release Notes:
- Fixed a cause of stutters when interacting with the agent
Summary:
- Added a rename action for agent threads in the sidebar.
- Persisted renamed thread titles and kept open thread views in sync.
Release Notes:
- Improved agent threads by allowing them to be renamed directly from
the sidebar.
Format `read_file` tool output in `cat -n` style: each line is prefixed
with its line number right-aligned in a 6-character field, followed by a
single tab, followed by the line's original content (newlines preserved,
including CRLF). Numbering reflects the actual file lines, so a ranged
read starting at line 42 emits `42` for its first line, not `1`.
For large files, content returned by `get_buffer_content_or_outline` is
**not** prefixed:
- The symbol outline path already conveys structure via its `[L100-150]`
annotations.
- The truncated first-1KB fallback (used when a file exceeds
`AUTO_OUTLINE_SIZE` and has no parseable outline) is wrapped in a
synthetic `# First 1KB of …` header, so its lines don't correspond to
real file line numbers.
Both cases are reported via `BufferContent::is_synthetic` (renamed from
`is_outline`).
Also updates the `edit_file` tool's input doc to describe the prefix
format and tell the model to strip it before constructing `old_text` /
`new_text`, preserving the original indentation that appears after the
tab.
Updates how we render `read_file` tool call outputs in the UI
(screenshots included in comments below).
Also fixes an existing bug where `read_file` tool call outputs would not
re-render their content code block when an older thread was restored
(the tool's `replay` hook was missing).
Closes AI-226
Release Notes:
- Improved how `read_file` tool output renders in the agent panel, with
a line-number gutter, and fixed it not re-rendering on restored threads
---------
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
## Summary
- Hide deleted skills immediately in Settings while deletion completes
- Refresh the skill index after creating a skill so Settings updates
without reopening
Closes AI-299
Release Notes:
- Fixed skill management so newly created and deleted skills update in
Settings immediately.
When `read_file` returns a file outline instead of full contents, the
result is now wrapped in a plain fenced code block rather than tagging
it with the file's path.
Previously, the outline was wrapped in a fenced block tagged with the
file path (e.g. `` ```crates/agent/src/tools/read_file_tool.rs ``).
Because the tag contains a slash, the markdown parser routed it through
`CodeBlockKind::FencedSrc`, resolved the file's language by path, and
ran the language's tree-sitter parser against the outline on every
paint. The outline is structural (e.g. `fn foo [L10-20]`), not actual
source for the file's language, so the parse was both expensive and
produced incorrect highlighting.
Because GPUI rebuilds the visible element tree on every window paint,
anything that triggers a repaint (cursor blink in the focused message
editor, animations, the turn timer, etc.) would re-run the tree-sitter
parse on the entire outline, throttling the frame rate while the tool
call was expanded.
This change adds an `is_outline_response` flag in `ReadFileTool::run`
and, when set, passes an empty tag to `MarkdownCodeBlock` so the
renderer sees `CodeBlockKind::Fenced` (no language). Plain monospace
formatting is preserved; the path tag is still used for the non-outline
(full file) case.
Adds two regression tests: one asserting the outline path uses an
untagged fenced block, and one asserting the full-file path keeps the
path tag (so the next person fixing this doesn't accidentally strip the
tag everywhere).
Also includes a small markdown-rendering follow-up:
`MarkdownElementBuilder::push_text` was recomputing the base text style
(cloning `base_text_style` and walking the style stack) twice per
highlighted token. For a code block with hundreds of highlight tokens,
that's hundreds of redundant `TextStyle` clones per paint. The style
stack does not change while runs are being attributed, so the style is
now computed once outside the loop and reused.
Closes AI-234
Release Notes:
- Improved scrolling smoothness in the agent panel when a `read_file`
tool call with a large file outline is expanded.
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:
- N/A
Currently, the `diagnostics` tool queries the current state of the
workspace. However, if the LSP is slow to update diagnostics, this can
lead to stale diagnostics being given to the agent.
This PR changes the `diagnostics` tool to attempt to pull fresh
diagnostics. If it fails, it informs the agent and falls back to the old
behaviour (not all LSPs support pull-based diagnostics).
Release Notes:
- N/A or Added/Fixed/Improved ...
Removes the `skills` feature flag now that Skills are ready to ship to
all users. Cleans up all `cx.has_flag::<SkillsFeatureFlag>()` gates
across the agent, agent_ui, prompt_store, and title_bar crates, drops
the now-unused `feature_flags` dependency from `prompt_store` and
`title_bar`, and removes the dead `update_flags(true, vec!["skills"])`
calls from the agent's skills tests.
Closes AI-269
Release Notes:
- Enabled Skills for all users.
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
Co-authored-by: Martin Ye <martinye022@gmail.com>
Closes AI-267
This PR adds a skills subpage in the settings UI, where we display
global skills in the user tab and project skills in the corresponding
project tab. The approach taken here was the simplest one out of the
possible avenues we could've taken to implement this (which would
possibly require bigger refactors), given this is potentially the very
first page in the settings UI where we're displaying stuff that does not
correspond to data available in the `settings.json`.
Important to note that a major limitation of the global approach is that
it's dependent on the native agent having loaded the skill index,
meaning there's an edge case where, if you open the settings UI _before_
having opened the agent panel, you won't immediately see the available
skills. Something to discuss but that it felt like a viable option for a
first ship.
Release Notes:
- Agent: Added a skills section to the settings UI.
In the interactive MCP OAuth flow, the MCP client registers itself with
the authorization in one of three ways:
- Client ID Metadata Document aka CIMD (recommended default). This is
already implemented: https://zed.dev/oauth/client-metadata.json.
- Dynamic Client Registration (DCR). This is the traditional method.
Also already implemented in Zed.
- Pre-registration: the client is registered out of band, typically in
the IdP or SaaS provider's UI. You get a client id and maybe a client
secret, that have to be provided by the MCP client when it wants to
exchange an access token. This is what this pull request is about.
This PR has two main parts:
- Allow users to configure a client id and optional client secret for an
MCP server in their configuration, under a new `oauth` key, and take it
into account
- Make the MCP server state and the configuration modal aware of the
intermediate states (client secret missing) and error cases stemming
from client pre-registration.
The client secret can be stored either in the system keychain or in
plain text in the MCP server configuration. The UI tries to steer user
towards the more secure option: the keychain.
<img width="715" height="201" alt="Screenshot 2026-04-10 at 16 48 06"
src="https://github.com/user-attachments/assets/5e64103e-6746-4ef0-8bd9-533d492b6912"
/>
<img width="884" height="544" alt="Screenshot 2026-04-10 at 16 47 07"
src="https://github.com/user-attachments/assets/0e35bb3c-cbc4-4e8c-a713-66323597b2e2"
/>
<img width="785" height="558" alt="Screenshot 2026-04-10 at 16 47 23"
src="https://github.com/user-attachments/assets/03339187-1508-461a-87ae-a7c2647df9a5"
/>
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
Closes
https://github.com/issues/assigned?issue=zed-industries%7Czed%7C52198
**Note for the reviewer: I know how busy the AI team is at the moment so
please treat this as low priority, we don't have signal that this is a
highly desired feature. It's a rather large PR, so I'm happy to pair
review / walk through it.**
Release Notes:
- Added support for OAuth client pre-registration (client id, client
secret) to the built-in MCP client.
This PR fixes a panic that could occur in the `edit_file` tool where
streaming in text could split in the middle of a multibyte character.
Closes FR-3 and [ZED-7ZX](https://zed-dev.sentry.io/issues/7480598098).
Release Notes:
- Fixed a panic that could occur when streaming in text with the
`edit_file` tool.
Closes AI-266
This PR adds a built-in skill called `create-skill`, which allows the
Zed agent to have access to a skill that teaches it how to properly
create skills for Zed. You can manually invoke it as well as just
letting the model auto-invoke it in case your prompt suggests creating a
new skill.
Release Notes:
- Agent: Added a built-in skill called `create-skill` to make the Zed
agent informed about how to do that.
---------
Co-authored-by: Richard Feldman <richard@zed.dev>
