Implements automatic label generation for VSCode tasks that don't have
explicit 'label' fields, matching VSCode's behavior.

Changes:
- Made label field optional in VsCodeTaskDefinition deserialization
- Implemented custom deserializer to auto-generate labels:
  - npm tasks: 'npm: {script}' (e.g., 'npm: start')
  - shell tasks: first word of command (e.g., 'echo')
  - gulp tasks: 'gulp: {task}' (e.g., 'gulp: build')
  - fallback: 'Untitled Task'
- Added test data file with tasks without labels
- Added test cases

Closes #47749

Release Notes:

- Fixed: VSCode tasks.json files with tasks missing explicit `label`
fields now parse correctly. Labels are auto-generated matching VSCode's
behavior (e.g., "npm: start").

When two Zed instances share the same data directory (e.g. a release
build and a dev build running simultaneously), SQLite operations can
fail with "database is locked" (error code 5), surfacing as a "Failed to
Launch" error in the agent panel.

The root cause is `PRAGMA busy_timeout=1` in `crates/db/src/db.rs`,
which gives SQLite only 1ms to wait for a write lock before giving up.
With WAL mode, the actual lock hold times are microseconds — the problem
isn't long-held locks, it's that we give up before even trying to wait.
During startup, both instances hit the DB heavily for workspace
restoration, so even tiny overlaps fail.

This changes `busy_timeout` from 1ms to 500ms, giving SQLite more room
to retry without (hopefully) any perceptible delay to the user.

Closes AI-20

Release Notes:

- N/A

This PR actually fixes two issues:
- the thread title being overridden even after it's been manually
edited; as you go and come back from the thread history view, the edited
title would get swapped for the auto-summarized one
- the parent thread title sometimes displaying the title of a subagent
thread; this would also override the manual edit

- - -

- [x] Tests
- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- Agent: Fixed thread titles being overridden even when manually edited.

---------

Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>

Closes #ISSUE

- [ ] Tests or screenshots needed?
- [ ] Code Reviewed
- [ ] Manual QA

Release Notes:

- N/A

When users have the `multi-workspace` feature flag enabled (agent-v2),
the default dock position for the agent panel is changed from right to
left.

This adds a `update_default_settings` method to `SettingsStore` that
allows mutating defaults in place, then observes the
`AgentV2FeatureFlag` to update the agent dock default accordingly.
Because this modifies the defaults layer, user-configured dock positions
still take precedence.

Closes AI-15

(No release notes because multi-agent is feature-flagged.)

Release Notes:

- N/A

## Fix incorrect context size limits for GitHub Copilot Chat models

Fixes #44909

### Problem

The agent panel was displaying incorrect token limits for GitHub Copilot
models. Users reported that:
- The agent panel always showed a **128K token limit** for all GitHub
Copilot models, regardless of their actual context window size
- Claude models (e.g., Claude 3.7 Sonnet, Claude Opus 4.5) were showing
~90K instead of their actual 200K context window
- GPT-4o was showing 110K instead of its actual 128K context window
- Users could continue using models beyond the displayed limit, which
worked but was confusing

### Root Cause

The `max_token_count()` method in `copilot_chat.rs` was returning
`max_prompt_tokens` instead of `max_context_window_tokens`:

```rust
// Before (incorrect)
pub fn max_token_count(&self) -> u64 {
    self.capabilities.limits.max_prompt_tokens
}
```

GitHub's API returns three different token-related fields:
- `max_context_window_tokens`: The **full context window size** (e.g.,
200K for Claude 3.7)
- `max_prompt_tokens`: GitHub's limit for prompt input (e.g., 90K for
Claude 3.7)
- `max_output_tokens`: Maximum output tokens (e.g., 16K)

The `max_token_count()` method in the `LanguageModel` trait is expected
to return the **full context window size** — this is consistent with all
other providers (Anthropic returns 200K for Claude, OpenAI returns 128K
for GPT-4o, etc.).

### Solution

<img width="583" height="132" alt="Screenshot 2026-01-25 at 1 07 53 AM"
src="https://github.com/user-attachments/assets/847e2fdb-635d-44bc-a630-2d4867ba8c32"
/>


Changed `max_token_count()` to return `max_context_window_tokens`:

```rust
// After (correct)
pub fn max_token_count(&self) -> u64 {
    self.capabilities.limits.max_context_window_tokens as u64
}
```

### Impact

| Model | Before | After |
|-------|--------|-------|
| Claude 3.7 Sonnet | 90,000 | **200,000** |
| Claude Opus 4.5 | 90,000 | **200,000** |
| GPT-4o | 110,000 | **128,000** |

### Testing

Added a new test
`test_max_token_count_returns_context_window_not_prompt_tokens` that:

1. Deserializes model JSON with distinct `max_context_window_tokens` and
`max_prompt_tokens` values
2. Verifies Claude 3.7 Sonnet returns 200,000 (context window), not
90,000 (prompt tokens)
3. Verifies GPT-4o returns 128,000 (context window), not 110,000 (prompt
tokens)

All existing tests continue to pass:
```
running 4 tests
test tests::test_unknown_vendor_resilience ... ok
test tests::test_max_token_count_returns_context_window_not_prompt_tokens ... ok
test tests::test_resilient_model_schema_deserialize ... ok
test result: ok. 4 passed; 0 failed
```


Release Notes:

- copilot: Fixed incorrect context window size displayed for GitHub
Copilot Chat models in the agent panel.

Closes #46556

  ## Summary

- Fix "Property `ty` is not allowed" warning in `settings.json` for LSP
adapters registered via `register_available_lsp_adapter()`
- Add `available_lsp_adapter_names()` method to include these adapters
in schema generation
- Support `initialization_options` schema lookup for available adapters

  ## Problem

LSP adapters registered via `register_available_lsp_adapter()` were not
included in the settings JSON schema. This caused validation warnings
like:

  Property ty is not allowed

Even though `ty` is a built-in Python language server that works
correctly.

  **Affected adapters:**
  - `ty`, `py`, `python-lsp-server`
  - `eslint`, `vtsls`, `typescript-language-server`
  - `tailwindcss-language-server`, `tailwindcss-intellisense-css`

  ## Solution

  Schema generation now queries both:
  1. `all_lsp_adapters()` - adapters bound to specific languages
2. `available_lsp_adapter_names()` - adapters enabled via settings (new)

  Related: #43104, #45928 
  
  Release Notes:

- Fixed an issue where not all LSP adapters would be suggested for
completion, or recognized as valid in `settings.json`

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>

Just some relatively small UI adjustments, like adding the forward arrow
to make it clearer there's a hierarchy between the parent thread and the
subagent thread, and a check icon to comunicate the subagent thread is
done.

<img width="500" height="612" alt="Screenshot 2026-02-12 at 11  47@2x"
src="https://github.com/user-attachments/assets/d49319b5-9c19-435a-b5c7-424060fa0629"
/>

- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- N/A

Release Notes:

- Fixed an issue where a request could fail if an MCP server with names
containing whitespace was used

## Summary

When multiple MCP servers expose tools with the same name, Zed
disambiguates them by prefixing the tool name with the server ID from
settings.json. If the server ID contains spaces or special characters
(e.g., `"Azure DevOps"`), the resulting tool name like `Azure
DevOps_echo` violates Anthropic's API pattern `^[a-zA-Z0-9_-]{1,128}$`,
causing API errors:

> "Received an error from the Anthropic API: tools.0.custom.name: String
should match pattern '^[a-zA-Z0-9_-]{1,128}$'"

## Solution

Convert server IDs to snake_case (using the `heck` crate already
available in the workspace) before using them as prefixes during tool
name disambiguation.

| Server ID in settings.json | Disambiguated Tool Name |
|---------------------------|------------------------|
| `"Azure DevOps"` | `azure_dev_ops_echo` |
| `"My MCP Server"` | `my_mcp_server_echo` |

## Test plan

- [x] Added test case for server name with spaces ("Azure DevOps") in
`test_mcp_tool_truncation`
- [x] Verified existing tests pass
- [x] Manually tested with two MCP servers having overlapping tool names

After (left), Before (right):

<img width="2880" height="1800" alt="Screenshot_20251228_163249"
src="https://github.com/user-attachments/assets/09c4e8f0-e282-4620-9db3-3e2c7d428d15"
/>


🤖 Generated with (some) help from [Claude
Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>

Release Notes:

- Added `allow_extended_context` to the Bedrock settings which enables
1M context windows on models that support it

---------

Co-authored-by: Ona <no-reply@ona.com>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>

Normalize handling of empty tool call arguments across all LLM
providers. Many providers return empty strings for tool calls with no
arguments, which would previously fail JSON parsing.

- Created shared parse_tool_arguments() helper in provider/util.rs that
treats empty strings as empty JSON objects ({})
- Refactored 10 occurrences across 9 provider files to use the helper
- Ensures consistent behavior across all providers (anthropic, bedrock,
copilot_chat, deepseek, lmstudio, mistral, open_ai, open_router)

Closes: #48955

Release Notes:

- Fixed tool calls with no arguments failing when using certain LLM
providers

Closes #37525

By default, thread summary uses default_fast_model (if set), otherwise
default_model, which resolves to openrouter/auto for openrouter
provider. This may cause the summary to be generated by a different
model than the one used by the agent, potentially leading — in cases
such as Claude Opus 4.5 — to summary costs exceeding main agent
execution costs.
The current logic in registry.rs prioritizes default_fast_model over
default_model, which overrides the user-selected model (assigned only to
default_model). Setting default_fast_model = None for the OpenRouter
provider preserves the fallback to openrouter/auto when no model is
chosen, while respecting the user's explicit model selection when one is
provided.

```rust
    pub fn set_default_model(&mut self, model: Option<ConfiguredModel>, cx: &mut Context<Self>) {
        match (self.default_model.as_ref(), model.as_ref()) {
            (Some(old), Some(new)) if old.is_same_as(new) => {}
            (None, None) => {}
            _ => cx.emit(Event::DefaultModelChanged),
        }
        self.default_fast_model = maybe!({
            let provider = &model.as_ref()?.provider;
            let fast_model = provider.default_fast_model(cx)?;
            Some(ConfiguredModel {
                provider: provider.clone(),
                model: fast_model,
            })
        }); // This sets default fast model (in our case openrouter/auto)
        self.default_model = model;  //This sets default_model to user selected model
    }
```

And latter on :
```rust
    pub fn thread_summary_model(&self) -> Option<ConfiguredModel> {
        #[cfg(debug_assertions)]
        if std::env::var("ZED_SIMULATE_NO_LLM_PROVIDER").is_ok() {
            return None;
        }

        self.thread_summary_model
            .clone()
            .or_else(|| self.default_fast_model.clone()) // We pick fast_model over default model here
            .or_else(|| self.default_model.clone())
    }
```
Which results in user choice being ignored.

Proposed behavior:

Use the model explicitly selected by the user in Zed agent
configuration.
If no model is specified, fall back to the configured default.

The resolution is to set in :  provider/open_router.rs
```rust
fn default_fast_model(&self, _cx: &App) -> Option<Arc<dyn LanguageModel>> {
     None
}
```
This will have a consequence of default_fast_model not being provided
and falling back to user choice - but once the fast model is set via for
example a configuration property - the default_fast_model is picked over
default_model

Release Notes:

- open_router: Use user's default model when comments and thread summary

Closes #47404

Release Notes:

- Fixed MCP tool results not displaying after restarting Zed

Previously, when an MCP server returned a tool response with
`is_error: true`, the error content was incorrectly treated as
a successful result. This could mislead the LLM into thinking
the tool call succeeded when it actually failed.

Now we check the `is_error` flag and propagate the error message
properly, allowing the agent to handle failures appropriately.

Release Notes:

- N/A

---------

Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>

Small thing here, but there's no actual link back to the ruby-lsp docs,
like there is for other languages or ruby LSPs (like solargraph). This
should help users find the correct docs for configuring.

Release Notes:

- N/A

This PR adds ability to select and test audio input/output devices for
use in collaboration setting (which is what the team at Zed relies
heavily on). Currently, we only ever used whatever the system default is
and it worked well until it didn't - for some reason, when I am on my
Linux laptop, I am unable to force Zed to use my external mic +
headphones via external USB audio interface. With this PR, now I can
list all available devices and select the one I want.

There are still a couple of caveats that we should be aware of:
* I've decided to list *all* available devices meaning on Linux it is
quite possible that you may discover that what your desktop environment
is reporting to you is a significantly shorter list than what your sound
framework/hw is actually exposing. I think this makes sense given my
inexperience with audio drivers/devices and frameworks on various OSes
so that we get full control over what is available with the goal of
being able to come up with some filtering heuristic as we go along.
* We currently populate the list of available audio devices only once at
startup meaning if you unplug your device while you have Zed running
this will not register until you restart Zed which is a PITA. However,
in order to keep the changes manageable I thought it would be best to do
minimal work in this regard now, and iterate on this some more in the
near future. After all, we don't really monitor device changes on any
platform except macOS anyhow, so it might be the case that when I get
round to implementing this I will have the opportunity to tackle both at
the same time.
* In order to get a valid list of all audio devices using `cpal` crate
(which is the building block of `rodio`), I had to bump `cpal` to 0.17,
and pin `rodio` to a more recent commit sha as a result, so if you see
any regressions, lemme know and/or feel free to revert this PR.
* Finally, I've done my best to integrate this with the settings UI, but
I am sure more could be done in terms of styling, etc.

Some screenshots:

<img width="1152" height="949" alt="Screenshot From 2026-02-12 11-40-04"
src="https://github.com/user-attachments/assets/e147c153-1902-49d6-bf68-3ac317a6a7b0"
/>
<img width="1152" height="949" alt="Screenshot From 2026-02-12 11-40-16"
src="https://github.com/user-attachments/assets/b4e9a2f8-b38e-4de0-b910-067cc432b5bc"
/>


Release Notes:

- Added ability to select audio input/output devices as part of
Collaboration page in Settings. Added ability to test selected devices
with a simple playback loop routing input directly into output for
easier debugging of your audio devices.

---------

Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>

Release Notes:

- N/A

Release Notes:

- N/A

Before:
<img width="371" height="93" alt="before"
src="https://github.com/user-attachments/assets/f2e9ba9c-4ef7-4533-b565-9d977d60ae79"
/>

After: 
<img width="371" height="93" alt="after"
src="https://github.com/user-attachments/assets/b385f0bc-3b23-4a3c-8bf3-639afad10e1e"
/>

Release Notes:

- Improves function parameter highlighting for Bash

Co-authored-by: ozacod <ozacod@users.noreply.github.com>

This PR makes the remote projects a bit more consistent with other modal
dialogs by adding a footer to better expose the "open" and "open in new
window" options.

<img width="550" height="888" alt="Screenshot 2026-02-12 at 9  53@2x"
src="https://github.com/user-attachments/assets/1d7a67c4-fc69-40db-8dc4-8099bde4ebd7"
/>

- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- N/A

Part of https://github.com/zed-industries/zed/issues/9461. Similar PRs:
- https://github.com/zed-industries/zed/pull/46722
- https://github.com/zed-industries/zed/pull/39683
- https://github.com/zed-industries/zed/pull/39801


## Release Notes:

- Allowed highlighting for case statement items for users and theme
authors via the `string.regex` syntax property.
- Allowed highlighting for special variables via `variable.special`

## Screenshots

| **Before** | **After** |
|:--:|:--:|
| <img width="727" height="922" alt="image"
src="https://github.com/user-attachments/assets/15126713-1f02-40f2-8115-0deb5476aebd"
/> | <img width="742" height="900" alt="image"
src="https://github.com/user-attachments/assets/e178934e-5735-448d-abb2-2d2ad08a9c8f"
/> |

Closes #47527
## Summary
The include/exclude filters in Project Search now support standard glob
brace syntax like `{a,b}`.
**Before:** `crates/{search,project}/**/file.rs` would error with
"unclosed alternate group"
**After:** Pattern correctly matches files in both `crates/search/` and
`crates/project/`
## Implementation
Added `split_glob_patterns()` function that splits by comma only when
not inside braces, preserving the `{a,b}` syntax that `globset` natively
supports.

Release Notes:

- Added support for `{a,b}` glob syntax in project search
include/exclude filters

Here is the screenshot of before and after.

Before:
<img width="1414" height="408"
alt="{0233D673-E876-4CFC-81BC-E0DE778CA382}"
src="https://github.com/user-attachments/assets/f30170a8-6cb5-4ee6-9c30-fb21b2c18be5"
/>

After:
<img width="1271" height="635"
alt="{321F7C80-13A0-4478-BCE9-530F1824A9E2}"
src="https://github.com/user-attachments/assets/0bd70a01-d576-438f-9286-01aebb08aeaf"
/>

Highlights the shebang line as a directive instead of a comment.

Before:
<img width="316" height="99" alt="before"
src="https://github.com/user-attachments/assets/d77a7fbd-4610-4282-b48a-c994d37401b6"
/>

After:
<img width="316" height="99" alt="after"
src="https://github.com/user-attachments/assets/7861ba9e-f64d-45be-aa0a-9e98a82b3746"
/>

Release Notes:

- Added shebang highlight support for Bash

Co-authored-by: ozacod <ozacod@users.noreply.github.com>

Follow-up to https://github.com/zed-industries/zed/pull/46641.

In the PR linked above, I had introduced a dropdown that'd show up in
the title bar when the workspace contained more than one project.
Although that helped improve the multi-project use case, it created some
quirky designs:

- The project dropdown and the recent project pickers looked too
different from one another
- The transition between the 2 project case to the 1 project scenario,
from the dropdown, was not great, because you'd be then seeing the
bigger recent projects picker
- The `workspace: switch project` action was still reachable in the
command palette even if you had one project in the workspace

So, what this PR does is essentially fixing all of this by consolidating
it all in the Recent Projects picker. If you are in a multi-project
scenario, the picker will display a section with all of the projects on
the workspace allowing you to activate each one of them. The picker also
looks simpler when you reach it by clicking on the project name in the
title bar, as opposed to through the keybinding. I've then removed the
project dropdown code as well as the action, given we don't need them
anymore due to the consolidation. Lastly, I tackled the inconsistent
wording used between "Folders", "Projects", and "Workspaces".

Here's the result:


https://github.com/user-attachments/assets/9d8ef3e3-e57b-4558-9bc0-dcc401dec469

- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- Workspace: Improved the recent projects picker by making it also
display active projects in case of a multi-project workspace.

This patch updates the description of the `edit_file` tool to recommend
models to use the `move_path` tool instead of the `terminal` tool to
move or rename files. The `move_path` tool is more specific and shall be
preferred as it provides a better UI and dedicated permissions.

Release Notes:

- N/A

Add workspace::CloseItemInAllPanes action that closes the active
item's buffer in every pane where it's open, matching Vim's `:bdelete`
semantics. Pane layout is preserved, only the buffer is removed.

`:bd` respects pinned tabs, `:bd!` overrides them and skips save.

Also refactors the tab switcher's close button to use the new
`close_items_with_project_path` method, removing duplicated logic.

Release Notes:

- Vim: `:bd` (`:bdelete`) now closes the file in all panes where it's
open
- Added `workspace::CloseItemInAllPanes` action to close a file across
all panes

Co-authored-by: David Baldwin <baldwindavid@gmail.com>

## Changes
- Hide `assistant` namespace when `agent.enabled = false`
- Added test coverage for assistant command visibility

## Testing
- Verified manually that commands are hidden/shown dynamically
- Added test assertions in
[test_agent_command_palette_visibility](cci:1://file:///media/omchillure/Projects/zed-oss/zed/crates/agent_ui/src/agent_ui.rs:525:4-657:5)
- Test passes: `cargo test -p agent_ui
test_agent_command_palette_visibility`

## Video : 
[Screencast from 2026-02-11
21-01-30.webm](https://github.com/user-attachments/assets/bbdb3e44-4ba9-4def-ad05-74e412bc5dba)


## Release Notes:

- Fixed assistant commands (Copy Code, Insert Into Editor, etc.)
remaining visible in the command palette when the agent is disabled in
settings.

Release Notes:

- N/A

Closes #47910


https://github.com/user-attachments/assets/de2d18ef-46fd-4201-88e4-6214ddf0fd06


- [x] Tests or screenshots needed?
- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- Added support for installing ACP agents via ACP registry in remote
projects

---------

Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>

Release Notes:

- N/A

| On | Off |
|--------|--------|
| <img width="1152" height="402" alt="Screenshot 2026-02-11 at 4  28
2@2x"
src="https://github.com/user-attachments/assets/239d64c2-5ae8-4e2c-8aee-2e01d17e81bb"
/> | <img width="1152" height="402" alt="Screenshot 2026-02-11 at 4 
28@2x"
src="https://github.com/user-attachments/assets/e0baa0ac-1855-45ce-92ba-facc83fef83f"
/> |

- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- N/A

## Summary

Creating a new file via the file picker incorrectly used the focused
file's directory as the target even when that file did not belong to any
open worktree (e.g., Zed opened to a single file, settings.json focused
without a worktree, or an external file focused). This PR changes the
selection logic so the picker only uses the focused file's worktree if
that file actually belongs to one of the visible project worktrees;
otherwise, it falls back to the existing project heuristic (query-root
match or project default), which prevents misdirected file creation.
This addresses
[zed-industries/zed#41940](https://github.com/zed-industries/zed/issues/41940).

---

## Problem

### Scenarios that errored or created in the wrong place:

1. **Zed opened to a single file from the CLI** (no worktree)
- Create New was offered and then failed or targeted a non-project
directory

2. **No worktree open with settings.json focused**
   - Same failure mode as above

3. **A worktree is open but settings.json is focused**
   - Create New used settings.json's directory

4. **A worktree is open but an external (non-worktree) file is focused**
   - Create New used the external file's directory

### Root Cause

`set_search_matches` unconditionally overwrote `expect_worktree` using
the `currently_opened_path` worktree_id, even if the focused file was
not part of any visible worktree.

---

## Fix

### Query-derived worktree remains primary:

- Try to match the query path against the roots of visible worktrees
- If it matches, use that worktree and strip the root prefix from the
query to get the relative path

### Only use the focused file as a secondary signal if it is relevant:

- Check whether the focused file's `worktree_id` exists within visible
worktrees
- Only then override `expect_worktree`

If no worktree is determined (e.g., no worktrees are open), Create New
is not offered.

---

## Implementation Details

- **Iterate over `&available_worktree`** when scanning roots and clone
the matched entity to avoid moving out of the iterator

- **Validate focused file worktree membership:**
- Compute `focused_file_in_available_worktree` by scanning visible
worktrees for a matching id
  - Override `expect_worktree` only if that check passes

- **Preserve existing guard rails for Create New:**
- Only push `Match::CreateNew` when a concrete `expect_worktree` is
present and the query doesn't end with a trailing separator

---

## Key Code Changes

### Before

Always overwrote `expect_worktree` with the focused file's
`worktree_id`, even for external or non-project files.

### After

Only override `expect_worktree` when the focused file belongs to a
visible worktree. Otherwise, keep the query-derived or default project
worktree.

---

## User-Facing Behavior

### No Worktree Open

*Example: Zed launched with a single file or only settings.json visible*

- The file picker will **not** offer "Create New"

### Worktree Open + Non-Project File Focused

*Example: A non-project file or settings.json is in focus*

- "Create New" is offered
- New file is created within the project worktree (based on root match
or project default)
- New file is **never** created beside the external file

### Multiple Worktrees Open + Query Rooted to One

*Example: Query specifies a particular worktree root*

- The worktree is selected by root-name match
- Project default selection applies if no match is found

---

## Tests

### Added:
`test_create_file_focused_file_not_belong_to_available_worktrees`

1. Set up two worktrees A and B; open an external file that belongs to
neither
2. Use the file picker to create "new-file.txt"
3. Assert the new file opens in an editor whose
`ProjectPath.worktree_id` equals either A or B, and the relative path is
"new-file.txt"

Existing tests for Create New, absolute/relative matching, and
multi-worktree behavior continue to pass.

---

## Reproduction Steps (Pre-Fix)

1. Launch Zed with a single file:
   ```bash
   zed /tmp/foo.txt
   ```
   Or open settings.json with no project

2. Open the file finder and type a new filename, then press Enter

3. Observe Create New trying to use the focused file's directory or
failing unexpectedly

---

## Expected vs Actual

### Expected:

- No Create New when there is no project worktree
- When a project exists, Create New targets the appropriate worktree,
not the focused external file's directory

### Actual (pre-fix):

- Create New used the focused file's directory, even if it was external
or unrelated to the project

---

## Migration and Compatibility

- No user configuration changes required
- Behavior now aligns with user expectation: Create New is only offered
when a project worktree is available and it always targets a project
worktree

---

## Reference

**Fixes:**
[zed-industries/zed#41940](https://github.com/zed-industries/zed/issues/41940)
Fixes #41940 

---

## Appendix: Code Snippets

### Guard before overriding with focused file:

```rust
let focused_file_in_available_worktree = available_worktree.iter().any(|wt| wt.read(cx).id() == worktree_id);

if focused_file_in_available_worktree { 
    expect_worktree = project.worktree_for_id(worktree_id, cx); 
}
```

### Root-based worktree selection with non-moving iteration:

```rust
for worktree in &available_worktree { 
    if query_path.strip_prefix(worktree.read(cx).root_name()).is_ok() { 
        expect_worktree = Some(worktree.clone()); 
        …
    } 
}
```

---

This PR includes a targeted test ensuring that when the focused file is
outside all worktrees, Create New still creates within the project
worktree(s), preventing regressions.

---
## Release Notes

- Fixed "Create New" in the file picker targeting the wrong directory
when a non-project file was focused.
---

---------

Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

This makes the `zed --add <PATH>` command use the window it was run from
when run from a Terminal Panel. I run into this paper cut quite a lot
working with multiple projects and preferring to create new files
through the CLI instead of the GUI.


**Before**
With two windows open, running `zed --add a.txt` in one window's
terminal might open the file `a.txt` in the other window.

[Screencast from 12-17-2025 02:24:45 AM - zed --add bug
before.webm](https://github.com/user-attachments/assets/30816add-91e1-41c3-b2e3-6a0e6e88771a)


**After**
With this change, it will use the window of the Terminal Panel.

[Screencast from 12-17-2025 02:16:09 AM - zed --add bug
after.webm](https://github.com/user-attachments/assets/5141518e-5fb0-47d1-9281-54c0699ff7f5)



Release Notes:

- Improved `zed --add` command to prefer window it was run from

Co-authored-by: Kirill Bulatov <kirill@zed.dev>

Release Notes:

- N/A

Replace `FuturesUnordered` with `FuturesOrdered` to maintain terminal
tab ordering when restoring a workspace.
Also clamp `pinned_count` to `items_len()` to prevent panics when fewer
terminals are restored than expected.

The changes:
1. Order preservation: `FuturesUnordered` → `FuturesOrdered` ensures
terminals restore in their original order
2. Bounds fix: `.min(pane.items_len())` prevents setting pinned count
higher than actual items

Closes #44463

Release Notes:

- Preserved terminal order and fixed pinned count on workspace restore

---------

Co-authored-by: Kirill Bulatov <kirill@zed.dev>

Release Notes:

- Fixed inlay hints being rendered as new inserted words in word based
diff highlighting

---------

Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>

- [x] Tests or screenshots needed?
- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- N/A

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Caused by https://github.com/zed-industries/zed/pull/48763 and
https://github.com/zed-industries/zed/pull/48800

Release Notes:

- N/A *or* Added/Fixed/Improved ...

This PR completely subsumes
https://github.com/zed-industries/zed/pull/46720

<img width="574" height="496" alt="image"
src="https://github.com/user-attachments/assets/14ee9185-0be6-49cf-b5fd-114e61915341"
/>

Release Notes:

- Added Python Environments to REPL kernel selection
- List active toolchain/python environment as the recommended kernel for
REPL usage

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>

Closes #30938

Release Notes:

- Fixed: Unable to load relative path JSON schema for YAML validation
(#30938)


This patch follows the vscode LSP client logic, see
[`jsonClient.ts`](https://github.com/microsoft/vscode/blob/cee904f80cc6d15f22c850482789e06b1f536e72/extensions/json-language-features/client/src/jsonClient.ts#L768-L770).
The `url` of the JSON schemas settings and the YAML schemas settings
should be resolved to an absolute path in the LSP client when it is
submitted to the server.

---------

Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>

Closes #ISSUE

- [ ] Tests or screenshots needed?
- [ ] Code Reviewed
- [ ] Manual QA

Release Notes:

- N/A

Add support for detecting Go files that can be executed directly via
shebang-style comments (e.g., '// usr/bin/env go run "$0" "$@"; exit
"$?"').

This allows Zed to recognize Go scripts with first-line comments
containing 'go run' as executable Go files, similar to how other
languages detect shebangs or mode lines.

Reference: https://stackoverflow.com/q/7707178/1458343

Release Notes:

- Improved: Go language detection now recognizes executable Go scripts
with first-line 'go run' comments.

Release Notes:

- Added agent panel restoration. Now restarting your editor won't cause
your thread to be forgotten.

---------

Co-authored-by: Anthony Eid <56899983+Anthony-Eid@users.noreply.github.com>
Co-authored-by: Eric Holk <eric@zed.dev>
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
Co-authored-by: Anthony Eid <anthony@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Cameron Mcloughlin <cameron.studdstreet@gmail.com>

We're going to re-apply these after landing the multiworkspace branch.

Release Notes:

- N/A

Reverts zed-industries/zed#48956

Closes #ISSUE

- [ ] Tests or screenshots needed?
- [ ] Code Reviewed
- [ ] Manual QA

Release Notes:

- N/A

Release Notes:

- Swapped the default value for `agent.single_file_review` to `false`.
Agent diffs will no longer override the git diff in your buffer. You can
still review the agent's changes via the action log review button, or by
flipping this setting back to `true`

- **ci: Another stab at mtime-based freshness**

- [x] Tests or screenshots needed?
- [x] Code Reviewed
- [x] Manual QA

Release Notes:

- N/A