Richard FeldmanandMartinYe1234
356c8cae07
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>
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
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.