Kyle Kelley
fcf45c6dbe
`create_terminal_task` and `create_terminal_shell_internal` previously built their toolchain candidate list as `[active_editor_entry.path, ...visible_worktrees]` and used the first one with a persisted toolchain. A Python toolchain persisted for worktree A would leak into a terminal opened in worktree B of the same window: with a conda env selected for one project, every terminal in every other project of the window inherited that env's activation at startup. This scopes the candidate list to the worktree that contains the terminal's CWD. Both call sites now derive candidates from `find_worktree(path)`, where `path` is the terminal's resolved CWD (`spawn_task.cwd` or `active_project_directory`). If the path lives in a worktree, lookup runs scoped to that worktree's id. If not, no toolchain is applied. ## Design decision The previous fallback chain (active editor's worktree, then all visible worktrees) is removed entirely. Both fallbacks were sources of the leak: - "Active editor's worktree" is order-dependent: opening a terminal in worktree B picks up worktree A's toolchain because a file in A is focused. - "All visible worktrees" is worse, since the first worktree with any persisted toolchain wins. Workflows that relied on either fallback need to set the toolchain explicitly on the worktree where the terminal is opened. ## Coverage `cargo check -p project` is clean. There is no unit test for the cross-worktree case; that would require a multi-worktree Project fixture with persisted toolchains, which doesn't exist in the test suite today. Reproduction is straightforward: open a workspace with two folders, select a Python toolchain in one, open a terminal in the other, and observe the leaked activation script in the spawned shell. Release Notes: - Fixed Python toolchains persisted for one worktree leaking into terminals opened in other worktrees of the same workspace.
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking discussion)
Developing Zed
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
Zed source code is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked.
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.