## Summary
- refresh git auth headers before each per-crash iteration in
`background_agent_mvp`
- add guarded `git fetch`/`git checkout` handling so one candidate auth
failure doesn’t fail the entire run
## Context
- fixes the auth failure seen in workflow run 22106378719 (`fatal: could
not read Username for 'https://github.com'`)
- related Linear issue: BIZOPS-853
## Testing
- ruby -e "require 'yaml';
YAML.load_file('.github/workflows/background_agent_mvp.yml')"
Release Notes:
- N/A
## Summary
- add a new crash issue-linking subagent prompt
(`.factory/prompts/crash/link-issues.md`)
- add a scheduled/manual GitHub workflow for week-one background-agent
runs (`.github/workflows/background_agent_mvp.yml`)
- add Sentry candidate selection script to rank top crashes by
solvability × population (`script/select-sentry-crash-candidates`)
- add a local dry-run runner for end-to-end MVP execution without
push/PR actions (`script/run-background-agent-mvp-local`)
## Guardrails in this MVP
- draft PRs only (no auto-merge)
- reviewer routing defaults to: `eholk,morgankrey,osiewicz,bennetbo`
- pipeline order is: investigate -> link-issues -> fix
## Validation
- `python3 -m py_compile script/select-sentry-crash-candidates
script/run-background-agent-mvp-local`
- `python3 script/select-sentry-crash-candidates --help`
- `python3 script/run-background-agent-mvp-local --help`
---------
Co-authored-by: John D. Swanson <swannysec@users.noreply.github.com>
Closes#45507
There have been 5+ PRs attempting to fix Linux desktop icon association
by adding `StartupWMClass` back to the `.desktop.in` template (#15763,
#20644, #23459, #33019, #37962), all closed because `StartupWMClass` is
an X11-specific key that GNOME happens to misuse on Wayland, and the
correct fix per the FreeDesktop spec is to name the `.desktop` file to
match the app's Wayland `app_id` / X11 `WM_CLASS`. Refer:
https://github.com/zed-industries/zed/issues/12707#issuecomment-2168742761
The root cause is that `bundle-linux` was never updated to produce the
correct filename in the tarball. The only consumers of the tarball's
desktop file are `install.sh` and manual extractors. So this fix is for
people who download the tarball and extract it without `install.sh`. The
docs already tell them to rename, but as @wcbing points out, not
everyone reads that carefully.
We are now making `bundle-linux` produce the correctly named desktop
file from the start.
Release Notes:
- N/A
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
These prompts can be used to automatically diagnose and fix crashes
report in Sentry.
Usage:
1. Find a crash in Sentry. It will have an ID like ZED-123
2. In an agent, do a prompt like `Follow the instructions in
@investigate.md to investigate ZED-123`
3. Once the agent finds a repro, fix it in a new thread by saying
`Follow the instructions in @fix.md`
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Finn found out the hard way that the new cool tech does not quite work
at times. Back to the drawing board we go (at least partially).
Closes #ISSUE
Release Notes:
- N/A
This PR updates the Linux install script to support installing a
specific version of Zed via the
ZED_VERSION environment variable.
- If ZED_VERSION is set, that version will be downloaded.
- If ZED_VERSION is not set, the script defaults to the latest stable
version, preserving
existing behavior.
- Works for both Linux and macOS installs.
- Maintains compatibility with ZED_CHANNEL for preview builds.
This enhancement allows users to:
- Pin a specific Zed version for reproducible setups or CI workflows.
- Easily install older or known-good versions without manually
downloading release assets.
Usage examples:
- Install latest stable (default):
curl -f https://zed.dev/install.sh | sh
- Install specific version:
curl -f https://zed.dev/install.sh | ZED_VERSION=0.216.0 sh
Use this — it’s correct, concise, and clearly user-facing:
Release Notes
* **Added:** Support for installing a specific Zed version via the
`ZED_VERSION` environment variable in the install script (defaults to
`latest` when unset).
Fixes CI failures when the target dir is 0GB in size, which causes
`expr` to output a non-zero exit code per the posix spec.
See exit status section of
https://www.man7.org/linux/man-pages/man1/expr.1p.html
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This fixes the auto-update failure by ensuring cargo-bundle picks 'zed'
as the first binary.
**Problem:** `cargo metadata` returns binaries alphabetically, so
`visual_test_runner` was coming before `zed`. When cargo-bundle looks
for the first binary to bundle (without `--bin`), it was picking
`visual_test_runner` - which doesn't exist in release builds because it
requires the `visual-tests` feature.
The previous fix (#46163) added `--bin zed` to explicitly select the
binary, but this caused cargo-bundle to use the binary name ('zed')
instead of the bundle metadata name ('Zed Nightly'), breaking
auto-updates.
**Fix:** Rename the binary to `zed_visual_test_runner` so it comes after
`zed` alphabetically. This restores the original bundle script behavior
that has worked for years.
Also reverts the `--bin zed` workaround from #46163.
Release Notes:
- N/A
The visual_test_runner binary (added in #45259) has `required-features =
["visual-tests"]`, so it doesn't get built in release builds. However,
`cargo bundle` was trying to bundle all binaries defined in the zed
crate's Cargo.toml, causing it to fail when visual_test_runner doesn't
exist.
Adding `--bin zed` tells cargo bundle to only bundle the main zed
binary.
**Note:** The `cli` binary is unaffected by this change - it's a
separate package (`crates/cli`) that's built separately via `cargo build
--package cli` and manually copied into the app bundle afterward (line
337). It was never part of `cargo bundle`'s scope.
Fixes the nightly build failure:
https://github.com/zed-industries/zed/actions/runs/20740971838
Release Notes:
- N/A
Closes #ISSUE
Uses the existing `--dump-all-actions` arg on the Zed binary to generate
an asset of all of our actions so that the `docs_preprocessor` can
injest it, rather than depending on the Zed crate itself to collect all
action names
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Generated by AI.
`DocumentTypes.plist` declares `CFBundleTypeIconFile` as `Document` for
Zed’s document types, but the macOS bundle did not include
`Contents/Resources/Document.icns`, causing Finder to fall back to
generic icons.
This PR:
- Adds `crates/zed/resources/Document.icns` as a placeholder document
icon (currently derived from the app icon).
- Updates `script/bundle-mac` to copy it into the `.app` at
`Contents/Resources/Document.icns` during bundling.
- Adds `script/verify-macos-document-icon` for one-command validation.
## How to test (CLI)
1. Build a debug bundle:
- `./script/bundle-mac -d aarch64-apple-darwin`
2. Verify the bundle contains the referenced icon:
- `./script/verify-macos-document-icon
"target/aarch64-apple-darwin/debug/bundle/osx/Zed Dev.app"`
## Optional visual validation in Finder
- Pick a file (e.g. `.rs`), Get Info → Open with: Zed Dev → Change
All...
- Restart Finder: `killall Finder` (or log out/in)
@JosephTLyons — would you mind running the steps above and confirming
Finder shows Zed’s icon for source files after "Change All" + Finder
restart?
@danilo-leal — this PR ships a placeholder `Document.icns`. When the
real document icon is ready, replace
`crates/zed/resources/Document.icns` and the bundling script will
include it automatically.
Closes#44403.
Release Notes:
- TODO
---------
Co-authored-by: Matt Miller <mattrx@gmail.com>
Changes are made to `parse_path_with_position`:
we try to get the canonical, existing parts of
a path, then append the non-existing parts.
Closes#4441
Release Notes:
- Added the possibility to open a non-existing path using `zed` CLI
```
zed path/to/non/existing/file.txt
```
Co-authored-by: Syed Sadiq Ali <sadiqonemail@gmail.com>
Closes#40210
Previously attempted in #40423 and #42756. Third time's the charm?
Release Notes:
- Fixed encoding error in terms & conditions displayed when installing
Use
[`command`](https://www.gnu.org/software/bash/manual/bash.html#index-command)
instead of `which` to check if `wild` is installed.
Using `which` will result in an error being printed to stdout:
```bash
./script/install-wild
which: invalid option -- 's'
/usr/local/bin/wild
Warning: existing wild 0.6.0 found at /usr/local/bin/wild. Skipping installation.
```
Release Notes:
- N/A
Closes #ISSUE
The namespace runners mount the `target` directory to the cache drive,
so `rm -rf target` would fail with `Device Busy`. Instead we now do `rm
-rf target/* target/.*` to remove all files (including hidden files)
from the `target` directory, without removing the target directory
itself
Release Notes:
- N/A *or* Added/Fixed/Improved ...
We've had several outages with a proximate cause of "vercel is
complicated",
and auto-update is considered a critical feature; so lets not use vercel
for
that.
Release Notes:
- Auto Updates (and remote server binaries) are now downloaded via
https://cloud.zed.dev instead of https://zed.dev. As before, these URLs
redirect to the GitHub release for actual downloads.
Similar to #42246, we'd like to avoid having Vercel on the critical
path.
https://zed.dev/install.sh is served from Cloudflare by intercepting a
route on that page, so this makes the shell-based install flow vercel independent.
Release Notes:
- `./script/install.sh` will now fetch assets via
`https://cloud.zed.dev/`
instead of `https://zed.dev`. As before it will redirect to GitHub
releases
to complete the download.
This hopefully resolves the lingering test failures on linux,
but also adds some logging just in case this isn't the problem...
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
This is a follow up to #41482. When running `script/bundle-mac`, it will
upload debug symbols to Sentry if you have a `$SENTRY_AUTH_TOKEN` set. I
happen to have one set, so this script was trying to generate and upload
those. Whoops! This change skips the upload entirely if you're running a
local install.
Release Notes:
- N/A
One of the reasons we didn't spot that we were missing the telemetry env
vars for the production builds was that nightly (which was working) had
its own set of build steps. This re-uses those and pushes the env vars
down from the workflow to the job.
It also fixes nightly releases to upload all-in-one go so that all
platforms update in sync.
Closes#41655
Release Notes:
- N/A
I just pulled and ran a local build via `script/bundle-mac -l -i` but
found that the resulting bundle wasn't installed as expected. (me:
"ToggleAllDocks!! Wait! Where is it?!") Looking into, it looks like the
`-l` flag was removed in #41392, leaving the `$local_only` var orphaned,
which then left the `-i/$local_install` flag unreachable. I suspect that
this was unintentional, so this PR re-adds the `-l/$local_only` flag to
`script/bundle-mac`.
I ran the build again and confirmed that local install seemed to work as
expected. (ie "ToggleAllDocks!! 🎉")
While here, I also removed the last reference to `$local_arch`, because
all other references to that were removed in #41392.
/cc @osiewicz
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Reverts zed-industries/zed#41384
The branch-protection rules work much better when there is a Job that
runs every time and can be depended on to pass, we no longer have this.
Release Notes:
- N/A
Follow up for: #41304
Splits CI tests (cherry-picks and PRs only for now) into separate
workflows using `gh-workflow`. Includes a couple restructures to
- run more things in parallel
- remove our previous shell script based checking to filter tests based
on files changed, instead using the builtin `paths:` workflow filters
Splitting the docs/style/rust tests & checks into separate workflows
means we lose the complete summary showing all the tests in one view,
but it's possible to re-add in the future if we go back to checking what
files changed ourselves or always run everything.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Conrad <conrad@zed.dev>
I noticed we had some typos that were getting through CI, but it looks
like the new version of `typos` catches them. So I updated it and fixed
them.
Release Notes:
- N/A
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
Retrieval stats will now use polars to build a big data frame for
references with the cartesian product of LSP declarations and retrieved
declaration candidates (with all their score components) and rebuilds
the stats summary on top of it.
This data frame is written to a `.parquet` file, which we can load into
advanced analytics tools (such as Metabase), so we can explore our
scoring distributions and find ways to improve retrieval, and then train
the decision tree.
Release Notes:
- N/A
This moves some of the changes made in
https://github.com/zed-industries/zed/pull/39543 to the `publish_gpui`
script.
This PR also updates that script to use `gpui_` instead of `zed-` (where
possible)
Release Notes:
- N/A
This PR is a follow-up to #39090 and addresses two issues:
* Moves `conpty.dll` and `OpenConsole.exe` out of the `bin` folder to
prevent other programs from using them.
* Updates these files only after Zed exits, avoiding update failures due
to file locks.
Release Notes:
- N/A
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Closes#22657Closes#37863
# Background
Several users have noted that the terminal shipped with Zed on Windows
is either misbehaving or missing several features including lack of
consistent clearing behaviour. After some investigation which included
digging into the Microsoft Terminal project and VSCode editor, it turns
out that the pseudoconsole provided by Windows OS is severely outdated
which manifests itself in problems such as lack of clearing behaviour,
etc. Interestingly however, neither MS Terminal nor VSCode exhibit this
limitation so the question was why. Enter custom `conpty.dll` and
`OpenConsole.exe` runtime. These are updated, developed in MS Terminal
tree subprojects that aim to replace native Windows API as well as
augment the `conhost.exe` process that runs by default in Windows. They
also fix all the woes we had with the terminal on Windows (there is a
chance that ctrl-c behaviour is also fixed with these, but still need to
double check that this is indeed the case). This PR ensures that Zed
also benefits from the update pseudoconsole API.
# Proposed approach
It is possible to fork MS Terminal and instrument the necessary
subprojects for Rust-awareness (using `cc-rs` or otherwise to compile
the C++ code and then embed it in Rust-produced binaries for easier
inclusion in projects) but it comes at a cost of added complexity,
maintenance burden, etc. An alternative approach was proposed by
@reflectronic to download the binary from the official Nuget repo and
bundle it for release/local use. This PR aims to do just that.
There are two bits to this PR:
1. ~~when building Zed locally, and more specifically, when the `zed`
crate is being built, we will strive to download and unpack the binaries
into `OUT_DIR` provided by `cargo`. We will then set
`ZED_CONPTY_INSTALL_PATH=${OUT_DIR}/conpty` and use it at runtime in Zed
binary to tweak the loader's search path with that additional path. This
effectively ensures that Zed built from source on Windows has full
terminal support.~~ EDIT: after several discussions offline, we've
decided that keeping it minimal will serve us best, meaning: when
developing locally it is up to the developer of Zed to install
`conpty.dll` and put it in the loader's search path.
2. when bundling Windows release, we will download and unpack the nuget
package into Zed's bundle which will ensure it is installed in the same
directory as Zed by the installer.
**Note** I realise that 1. may actually not be needed - instead we could
leave that bit for the user who wants to run Zed from source to ensure
that they have `conpty.dll` in the loader's search path. I'd love to
hear opinions on this!
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Follows on from
https://github.com/zed-industries/zed/pull/37717#discussion_r2376739687
@dvdsk suggested this but I didn't get to it in the previous PR.
# Tested
```
; sudo rm /usr/local/bin/wild
; ./script/install-wild
Downloading from https://github.com/davidlattimore/wild/releases/download/0.6.0/wild-linker-0.6.0-x86_64-unknown-linux-gnu.tar.gz
Wild is installed to /usr/local/bin/wild
To make it your default, add or merge these lines into your ~/.cargo/config.toml:
[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=--ld-path=wild"]
[target.aarch64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=--ld-path=wild"]
```
```
; sudo rm /usr/local/bin/mold
; ./script/install-mold 2.34.0
Downloading from https://github.com/rui314/mold/releases/download/v2.34.0/mold-2.34.0-x86_64-linux.tar.gz
Mold is installed to /usr/local/bin/mold
To make it your default, add or merge these lines into your ~/.cargo/config.toml:
[target.'cfg(target_os = "linux")']
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=mold"]
```
Release Notes:
- N/A
Wild changed in 0.6.0 to using gzip rather than xz, and changed the
format of the package name.
Follows on from and fixes
https://github.com/zed-industries/zed/pull/37717
cc @dvdsk @mati865
Release Notes:
- N/A
There's a mismatch between the URL used here and the one that's referred
to in `build_zed_cloud_url`, which prevents using the script on Windows.
A previous PR changed the script to use `127.0.0.1` instead of
`localhost` because of supposed URL parsing issues, but we were unable
to reproduce those.
Release Notes:
- N/A
# Summary
Today, Zed uses Mold on Linux, but Wild can be significantly faster.
On my machine, Wild is 14% faster at a whole-tree clean build, 20%
faster on an incremental build with a minimal change, and makes no
measurable effect on runtime performance of tests.
However, Wild's page says it's not yet ready for production, so it seems
to early to switch for production and CI builds.
This PR keeps using Mold in CI and lets developers choose in their own
config what linker to use. (The downside of this is that after landing
this change, developers will have to do some local config or it will
fall back to the default linker which may be slower.)
[Wild 0.6 is out, and their announcement has some
benchmarks](https://davidlattimore.github.io/posts/2025/09/23/wild-update-0.6.0.html).
cc @davidlattimore from Wild, just fyi
# Tasks
- [x] Measure Wild build, incremental build, and runtime performance in
different scenarios
- [x] Remove the Linux linker config from `.cargo/config.toml` in the
tree
- [x] Test rope benchmarks etc
- [x] Set the linker to Mold in CI
- [x] Add instructions to use Wild or Mold into `linux.md`
- [x] Add a script to download Wild
- [x] Measure binary size
- [x] Recommend Wild from `scripts/linux`
# Benchmarks
| | wild 0.6 (rust 1.89) | mold 2.37.1 (1.89) | lld (rust 1.90) | wild
advantage |
| -- | -- | -- | -- | -- |
| clean workspace build | 176s | 184s | 182s | 5% faster than mold |
| nextest run workspace after build | 137s | 142s | 137s | in the noise?
|
| incremental rebuild | 3.9s | 5.0s | 6.6s | 22% faster than mold |
I didn't observe any apparent significant change in runtime performance
or binary size, or in the in-tree microbenchmarks.
Release Notes:
- N/A
---------
Co-authored-by: Mateusz Mikuła <oss@mateuszmikula.dev>
