Follow up Zed upstream updates: untranslated MCP entries, unrecognized write/default permission keys, sandbox_permissions, global ignore, commands, Windows global path

[dyoshikawa]

Summary

Seven Zed drifts, several of which make rulesync emit config Zed silently ignores: MCP servers are forwarded untranslated (a disabled server is emitted enabled), canonical write maps to a tool name Zed does not recognize, there is no way to set agent.tool_permissions.default, agent.sandbox_permissions is unauthorable, ignore has no global scope, commands are unsupported although Zed skills are the slash-command surface, and every global path is wrong on Windows.

Recent Releases

gh release list -R zed-industries/zed (stable channel), 2026-05 → 2026-07:

Version	Date	Relevant change
v1.4.2	2026-05-27	Skills shipped; Rules Library removed; global AGENTS.md added
v1.5.3	2026-06-03	Skill Creator; deprecated-Rules fixes
v1.7.2 / v1.8.2	2026-06-17 / 2026-06-24	Agent sandboxing prompts + network permission handling
v1.9.0	2026-07-01	skill tool wired into the Tool Permissions settings UI
v1.10.0	2026-07-08	Windows agent sandboxing protects Git metadata
v1.12.0	2026-07-23	Skill deletion UX (latest stable)

Docs commits: docs/src/ai/instructions.md added 2026-06-04 (#57614, AI docs restructure); docs/src/ai/sandboxing.md added 2026-06-23 (#59774), security review 2026-07-10 (#60291).

Dry-run baseline:

--targets zed --features "*" --dry-run
  → .rules, .zed/settings.json (ignore + mcp + permissions)
  → commands / subagents / hooks / checks all "does not support the feature … Skipping."
--targets zed --features "*" --global --dry-run
  → .config/zed/AGENTS.md, .config/zed/settings.json (mcp + permissions), 41 skills
  → NO ignore file (global ignore unsupported)

Gaps

1. mcp — context_servers entries are forwarded untranslated

• Upstream: Zed's context_servers value is a Rust #[serde(untagged)] enum (ContextServerSettingsContent in crates/settings_content/src/project.rs) with exactly three variants: Stdio (enabled: bool defaulting to true, remote: bool, flattened ContextServerCommand { command: PathBuf (serde-renamed from path), args, env, timeout }), Http (enabled, url, headers, timeout, oauth), and Extension (enabled, remote, settings). Docs: zed.dev/docs/ai/mcp.
• rulesync: ZedMcp.fromRulesyncMcp (src/features/mcp/zed-mcp.ts) writes rulesyncMcp.getMcpServers() verbatim, and getMcpServers() strips only targets/description/exposed/envVars. So canonical fields reach Zed unchanged:
  • disabled: true → Zed has no disabled key; it reads enabled (default true). A server the user disabled in rulesync is emitted enabled in Zed.
  • httpUrl: "..." (no url) → matches no variant; not recognized as an HTTP server.
  • command: ["npx", "-y", "pkg"] (array form, allowed by the canonical schema) → Zed expects a single string path plus args.
  • type: "sse" → Zed has no SSE variant.

2. ignore — private_files has no global scope

• Upstream: private_files is a worktree setting (WorktreeSettingsContent.private_files, crates/settings_content/src/project.rs; reference: all settings — "Private Files"). Zed layers default → user (~/.config/zed/settings.json) → project (.zed/settings.json), so the key is valid in the user settings file — which rulesync already writes for MCP and permissions in --global mode.
• rulesync: project only. ZedIgnore.getSettablePaths() (src/features/ignore/zed-ignore.ts) takes no global option and hardcodes .zed/settings.json; the processor's global target list is ["kiro", "kiro-cli", "kiro-ide"]. The --global dry-run emits no ignore file.
• Secondary, same adapter: the merge is additive-only — uniq([...existingPrivateFiles, ...patterns]) — so a pattern removed from .rulesync/.aiignore is never retracted from settings.json.

3. permissions — no way to set agent.tool_permissions.default

• Upstream: Zed's per-tool default is only rung 5 of the precedence ladder; rung 6 is the global agent.tool_permissions.default ("confirm" default / "allow" / "deny"), documented at tool permissions ("Rule Precedence", "Global Auto-Approve") and MCP ("Tool Permissions" — it is the mechanism for MCP tools).
• rulesync: ZedPermissions.fromRulesyncPermissions (src/features/permissions/zed-permissions.ts) only writes agent.tool_permissions.tools.<tool>; it spreads and preserves an existing top-level default but never sets it. The canonical all-tools key * is treated as an ordinary category and goes through toZedToolName("*") → tools["*"], which is not a Zed tool name and is silently ignored.

4. permissions — canonical write is not mapped to Zed's write_file

• Upstream: Zed's permission-gated tool list (supported tools, matching docs/src/ai/tools.md) is terminal, edit_file, write_file, delete_path, move_path, copy_path, create_directory, fetch, search_web, skill.
• rulesync: CANONICAL_TO_ZED_TOOL_NAMES (src/features/permissions/zed-permissions.ts) covers bash, read, edit, webfetch, websearch only. write is a documented canonical category (docs/reference/file-formats.md) and falls through the passthrough branch, so rulesync emits tools.write, which Zed does not recognize — the rule is silently inert. Same class of bug as the already-fixed web_search → search_web (Follow up Zed upstream updates: permissions web-search tool name should be search_web (not web_search) #1850).

5. permissions — agent.sandbox_permissions is not authorable

• Upstream: Zed shipped OS-level agent sandboxing with a persisted settings surface agent.sandbox_permissions: network_hosts (exact host or leading-*. wildcard), allow_all_hosts, write_paths, allow_fs_write_all, allow_unsandboxed, warn_confusable_unicode (SandboxPermissionsContent, crates/settings_content/src/agent.rs). Docs: sandboxing ("Persistent Sandbox Permissions"), added 2026-06-23 (#59774), security review 2026-07-10 (#60291); prompt/network work landed in v1.8.2 (2026-06-24) and v1.10.0 (2026-07-08).
• rulesync: writes only agent.tool_permissions into the same file. The tool-scoped zed override in .rulesync/permissions.json is the generic CanonicalPermissionsOverrideSchema (src/types/permissions.ts) — it carries only a permission block, so there is no slot for these keys. This is a different control plane from tool permissions (the Zed docs are explicit: tool permissions gate whether a call runs; the sandbox constrains what the running call can touch), so it cannot be expressed through the canonical allow/ask/deny model.

6. commands — unsupported, though Zed skills are the slash-command surface

• Upstream: Zed exposes every installed skill as a /name slash command and as @skill (manual invocation), and disable-model-invocation: true makes a skill user-invocable only (disable-model-invocation). Zed's own Rules→Skills migration does exactly this: "Non-default Rules become global Skills in ~/.agents/skills/, each with disable-model-invocation: true. They remain user-invocable by slash command or @-mention." (migrating to skills, v1.4.2, 2026-05-27).
• rulesync: unsupported — there is no zed-command.ts; the dry-run prints Target 'zed' does not support the feature 'commands'. Skipping.
• Precedent: src/features/commands/devin-command.ts emits rulesync commands as SKILL.md files on Devin's native skills surface for exactly this reason, using commandSlug / command-skill-ownership.ts to keep the commands feature from colliding with the skills feature's ownership of the same tree.

7. rules / mcp / permissions — global scope uses the wrong path on Windows

• Upstream: Zed's user config directory is %APPDATA%\Zed\ on Windows, not ~/.config/zed — ~/.config/zed/settings.json … Windows %APPDATA%\Zed\settings.json (configuring zed); and for the personal instructions file, "On Windows, the equivalent file is under %APPDATA%\Zed\AGENTS.md" (personal instructions, repeated in migrating to skills).
• rulesync: ZED_GLOBAL_DIR = join(".config", "zed") (src/constants/zed-paths.ts) is unconditional, and every global adapter uses it (zed-rule.ts, zed-mcp.ts, zed-permissions.ts). On Windows, --global writes to %USERPROFILE%\.config\zed\, which Zed never reads. Precedent for platform-branching a global dir already exists in src/constants/warp-paths.ts (WARP_LINUX_DIR vs WARP_WIN32_DIR).

Proposed Follow-up

1. Translate in ZedMcp.fromRulesyncMcp — disabled → enabled: !disabled, httpUrl → url, array command → string command + prepended args — and drop canonical-only keys Zed cannot read (type, transport, alwaysAllow, tools, kiro*, enabledTools/disabledTools, trust, networkTimeout, cwd). Warn (or skip) on type: "sse". Mirror the inverse in toRulesyncMcp().
2. Add global to ZedIgnore.getSettablePaths() (→ ZED_GLOBAL_DIR), register zed in ignoreProcessorGlobalToolTargets, and track rulesync-managed patterns so removals propagate (or at least warn on drop, matching the Kilo/Augment convention).
3. Map the canonical * category's catch-all rule onto agent.tool_permissions.default instead of emitting a tools["*"] entry, and round-trip it in toRulesyncPermissions().
4. Add write: "write_file" to CANONICAL_TO_ZED_TOOL_NAMES and its inverse. grep already matches Zed's tool name; glob has no permission-gated Zed counterpart (find_path is not in the gated list), so leaving it as passthrough is correct.
5. Give zed a dedicated permissions override schema (precedent: KimiCodePermissionsOverrideSchema, ClinePermissionsOverrideSchema, HermesPermissionsOverrideSchema in src/types/permissions.ts) carrying sandbox_permissions, merged non-destructively under agent in settings.json for both scopes, and re-extracted on import.
6. Add ZedCommand emitting .agents/skills/<slug>/SKILL.md (project) and ~/.agents/skills/<slug>/SKILL.md (global) with { name, description, disable-model-invocation: true }, reusing the Devin ownership/slug helpers, plus the Tool × Feature happy-path e2e case.
7. Branch ZED_GLOBAL_DIR on process.platform === "win32" → AppData/Roaming/Zed, following the warp-paths pattern. (Zed skills at ~/.agents/skills/ are home-relative on every platform and are unaffected.)

Non-gaps / inconclusive

• subagents — re-verified against agent profiles (current main): an agent.profiles.<id> entry carries only name, tools, enable_all_context_servers, context_servers, default_model. There is still no instructions/system-prompt field, so a rulesync subagent's body would be dropped. The spawn_agent tool (parallel agents) is a runtime affordance with no persisted per-agent definition file. The decision recorded in Follow up Zed upstream updates: subagents via Agent Profiles (agent.profiles in settings.json) #2033 still holds — no gap.
• hooks — Zed does have a hooks field, but on task templates in tasks.json (tasks#hooks). The only supported event is create_worktree (fires after Zed creates a linked Git worktree, with ZED_WORKTREE_ROOT / ZED_MAIN_GIT_WORKTREE). It is an editor/Git event, not an agent-lifecycle event; none of rulesync's canonical HOOK_EVENTS maps onto it. Not a material gap unless the maintainer wants a Zed-only event.
• checks — rulesync checks are code-review specs consumed only by Amp and Hermes. Zed has no equivalent surface.
• rules — Zed v1.4.2 deprecated the Rules Library, but both file surfaces rulesync targets are still documented and current: project .rules (first entry in the compatibility precedence list, project instructions) and personal ~/.config/zed/AGENTS.md. Aside from the Windows path (gap 7), no change needed.
• skills — frontmatter is still exactly name / description / disable-model-invocation (frontmatter fields); Zed says it "plans to include other fields promoted by the Agent Skills specification in the near future" — unconfirmed which, so nothing to follow yet. Paths match ZED_SKILLS_DIR_PATH. Minor, non-capability: Zed rejects skill names that are not [a-z0-9-], ≤64 chars, no leading/trailing or doubled hyphen; ZedSkillFrontmatterSchema accepts any string, so an invalid name generates a skill Zed silently fails to load.
• Follow up Zed upstream updates: subagents via Agent Profiles (agent.profiles in settings.json) #2033's last comment (2026-07-23) already noted three of these gaps (ignore global scope, MCP field translation, commands-as-skills) in passing, but the issue was closed on the subagents question only; nothing was filed or implemented for them, and all three were re-verified as present on 2026-07-26.

References

• https://zed.dev/docs/ai/mcp — the context_servers variants and the Tool Permissions note (gaps 1, 3).
• https://zed.dev/docs/reference/all-settings — private_files as a worktree setting valid in user settings (gap 2).
• https://zed.dev/docs/ai/tool-permissions — the precedence ladder, "Global Auto-Approve", and the supported-tool list (gaps 3–4).
• https://zed.dev/docs/ai/sandboxing — the persisted agent.sandbox_permissions surface (gap 5).
• https://zed.dev/docs/ai/skills — slash-command/@ invocation, disable-model-invocation, and the frontmatter field list (gap 6).
• https://zed.dev/docs/ai/rules#migrating-to-skills — Zed's own Rules→Skills migration, the model for gap 6, and a second statement of the Windows path (gap 7).
• https://zed.dev/docs/configuring-zed#user-settings and https://zed.dev/docs/ai/instructions#personal-instructions — the %APPDATA%\Zed\ user config dir (gap 7).
• https://zed.dev/docs/ai/agent-profiles and https://zed.dev/docs/ai/parallel-agents — used to re-confirm subagents is correctly unsupported.
• https://zed.dev/docs/tasks#hooks — the create_worktree task hook, checked and excluded.

[dyoshikawa]

Gaps 1, 3, 4 and 7 are fixed by #2450 (merged). Gaps 2, 5 and 6 stay open here.

Fixed

• Gap 1 (MCP translation). ZedMcp.fromRulesyncMcp now translates canonical servers into the context_servers shapes Zed parses instead of forwarding them verbatim: disabled: true → enabled: false (round-tripped back to disabled: true on import — the fail-open case where a disabled server was emitted enabled is gone), httpUrl → url, array command → string command + prepended args, canonical-only keys dropped (the drop list is derived from McpServerSchema itself, so unknown fields like oauth/settings pass through). A server Zed cannot start — sse/ws, remote with no url, local with no command — is skipped with a warning via the shared mcp-transport.ts helpers. A transport-less server is written as the extension-provided variant (canonical fields it cannot keep are dropped with a warning naming them) and imports into the tool-scoped zed.mcpServers block.
• Gap 3 (global default). The canonical * category's catch-all now sets agent.tool_permissions.default instead of an inert tools["*"] entry; round-tripped on import, with the stale tools["*"] spelling cleaned up on generate and read only as a fallback on import (the value Zed enforces must not lose to the one it ignores). Pattern-scoped *-category rules are dropped with a warning; a user-set default survives when canonical says nothing.
• Gap 4 (write mapping). write: "write_file" added to CANONICAL_TO_ZED_TOOL_NAMES (with inverse); the stale websearch → web_search claim in the docs was also corrected to search_web.
• Gap 7 (Windows path). getZedGlobalDir() resolves to AppData/Roaming/Zed (%APPDATA%\Zed) on win32 for rules, MCP and permissions; both spellings are declared to the shared-write derivation and the gateway ownership table, and the zed e2e specs use the platform-aware path (verified by the windows-latest E2E run on the PR).

Review hardening in the same PR: a null/array context_servers entry no longer crashes import, and a non-boolean enabled value stays in place instead of having a disablement intent silently erased.

Still open

• Gap 2 — global private_files scope + retraction. ZedIgnore remains project-only and additive-only.
• Gap 5 — agent.sandbox_permissions. Needs a dedicated zed permissions override schema; a different control plane from tool permissions.
• Gap 6 — commands as skills. Needs a ZedCommand emitting disable-model-invocation: true skills, following the Devin precedent, plus the Tool × Feature e2e case.

Accepted as known limitations (recorded in the PR review): the legacy Zed nested command: {path,...} import shape is not translated; a stale tools["*"] entry's pattern lists (inert in Zed) are not recovered on import.

[dyoshikawa]

Gap 2 is fixed by #2482 (merged). Gaps 5 and 6 stay open.

Fixed (gap 2 — global private_files scope + retraction)

• ZedIgnore.getSettablePaths() takes { global } and resolves the platform-aware user config dir (~/.config/zed/settings.json, %APPDATA%\Zed\settings.json on Windows); global is threaded through fromRulesyncIgnore/fromFile/forDeletion, zed is registered in ignoreProcessorGlobalToolTargets, and both global gateway entries now declare the ignore feature's ownership of private_files. getExtraSharedWritePaths() declares the other platform's spelling, so the shared-write derivation sees both everywhere — the same shape fix(zed): translate MCP servers, map the global default and write_file, use the Windows config dir #2450 used for MCP and permissions.
• The additive uniq([...existingPrivateFiles, ...patterns]) merge is gone (gap 2b). private_files is a replace-owned-keys block, so the generated list is authoritative and a pattern deleted from .rulesync/.aiignore is retracted in both scopes, while every other key in settings.json is still preserved and the file is never deleted.

Two things found in review and fixed in the same PR:

• Emitting private_files: [] when no patterns remain would have replaced Zed's populated default (**/.env*, **/*.pem, …) wholesale and switched its secret redaction off, so the key is removed instead of emptied.
• toRulesyncIgnore() built the rulesync source under the imported file's outputRoot, which put .rulesync/.aiignore in the user config dir on a global import. It is pinned to the project now, matching the Kiro precedent.

Covered by new ZedIgnore unit tests and both a global generate and a global import e2e case; the Windows E2E run is green on the merged head.

Still open

• Gap 5 — agent.sandbox_permissions. Needs a dedicated zed permissions override schema; a different control plane from tool permissions.
• Gap 6 — commands as skills. Needs a ZedCommand emitting disable-model-invocation: true skills, following the Devin precedent, plus the Tool × Feature e2e case.

Both remain design decisions, so this issue stays open for them.

[dyoshikawa]

Upstream update (re-check on 2026-07-30)

Window: 2026-05-01 → 2026-07-30 (v1.11.3, v1.12.0, v1.12.1, v1.13.1). Gaps 1, 3, 4, 7 confirmed fixed by #2450 and gap 2 by #2482. Gaps 5 (agent.sandbox_permissions) and 6 (commands-as-skills) re-verified still present; one addition to gap 5's field list — SandboxPermissionsContent has since gained warn_ntfs_grants (crates/settings_content/src/agent.rs). The releases in the window add no new AI configuration surface (UI/ACP-runtime/bugfix only).

Additional or changed gaps (not previously recorded)

1. permissions — canonical read maps to a tool Zed does not gate. Zed's permission-gated tool list is terminal, edit_file, write_file, delete_path, move_path, copy_path, create_directory, fetch, search_web, skill (tool-permissions doc); read_file is in Zed's own EXCLUDED_TOOLS ("Read-only / low-risk tools that don't call decide_permission_from_settings", crates/settings_ui/src/pages/tool_permissions_setup.rs, kept exhaustive by a compile-time test), together with grep, find_path, list_directory. CANONICAL_TO_ZED_TOOL_NAMES (src/features/permissions/zed-permissions.ts) maps read → read_file, and grep/glob pass through — all three produce agent.tool_permissions.tools.<name> entries Zed never consults, silently inert. Worse, docs/reference/file-formats.md tells users migrating off the deprecated ignore feature to move deny patterns into read — for Zed that produces a no-op; Zed's real read-denial surface is private_files, which the ignore feature already owns. Fix: drop read/grep/glob from the Zed emission with a warning naming private_files, remove the stale read → read_file claim from file-formats.md, optionally fold read deny patterns into private_files (Reasonix-style).
2. permissions — canonical MCP categories not translated to mcp:server:tool. Zed's key format is mcp:<server>:<tool> with the per-tool default as the primary mechanism, since pattern rules match against an empty string for MCP tools (MCP doc). rulesync's canonical mcp__<server>__<tool> passes through verbatim as a key Zed never looks up; file-formats.md's claim that mcp:<server>:<tool> keys "pass through unchanged" only works if users hand-author Zed's spelling into the shared block, which then leaks into every other target. Cursor / Kimi Code / Grok CLI / Kilo all translate the canonical form; Zed does not. Fix: translate mcp__… ⇄ mcp:… both directions; drop pattern-scoped rules within an MCP category with a warning, keeping the * rule as the per-tool default.
3. permissions / ignore — cross-scope accumulation, not replacement. private_files and always_allow/always_deny/always_confirm are ExtendingVecs whose merge_from is extend_from_slice (crates/settings_content/src/settings_content.rs) — default, user and project layers accumulate; a later layer cannot shorten an earlier one. rulesync models both features as replace-owned, correct within one file but not across scopes: a rule flipped from deny to allow leaves the old global always_deny entry in place, where it wins (rung 2 of the precedence ladder); a retracted project private_files pattern is still enforced from global. Also, file-formats.md's rationale for removing an empty private_files key ("any user or project value replaces wholesale, so an empty array would switch redaction off") is factually wrong under ExtendingVec — the resulting behavior is fine, the stated reason is not. Fix: correct the docs rationale, document cross-scope accumulation, and warn on conflicting actions between project and global Zed configs.

Re-verified non-gaps

hooks (create_worktree still the only event), subagents (AgentProfileContent unchanged; spawn_agent/create_thread are runtime tools in EXCLUDED_TOOLS), rules (.rules precedence unchanged; personal AGENTS.md platform-branched after #2450), skills (frontmatter unchanged; both scopes emitted).

References

• https://zed.dev/docs/ai/tool-permissions#supported-tools — the gated-tool list (new gap 1).
• https://zed.dev/docs/ai/mcp — the mcp:<server>:<tool> key format and empty-string pattern matching (new gap 2).
• zed-industries/zed: crates/settings_ui/src/pages/tool_permissions_setup.rs (EXCLUDED_TOOLS), crates/settings_content/src/settings_content.rs (ExtendingVec::merge_from), crates/settings_content/src/agent.rs (warn_ntfs_grants, AgentProfileContent).

[dyoshikawa]

Landed the inert-emission bug and the wrong docs recorded in the 2026-07-30 re-check as #2581 (merged).

Zed's gated tool list does not include read_file, grep, find_path or list_directory — they are in Zed's own EXCLUDED_TOOLS and never call decide_permission_from_settings — so the canonical read, grep and glob categories were producing agent.tool_permissions.tools.<name> entries Zed never consults. Those categories (and a category naming one of those Zed tools directly) are no longer emitted; the drop is warned about when the category carried a deny or ask rule, naming private_files as the real read-denial surface. An allow-only rule is dropped silently, since Zed leaving those tools ungoverned is what it asked for.

One deliberate deviation from the recorded fix: an inert entry an earlier version wrote is not cleaned up. Unlike tools["*"], read_file/grep are real Zed tool names, so rulesync cannot tell its own earlier output from an entry the user wrote — and since Zed ignores it either way, leaving it costs nothing while deleting it could not be undone. Import still reads such an entry back as the canonical category, and the docs say to remove it by hand if you want it gone.

docs/reference/file-formats.md was wrong in two places, both corrected: the Zed permissions section listed read → read_file among the working mappings (and now also records that the global default does not reach these tools either), and the "Migrating to permissions" guidance told users moving off the deprecated ignore feature to put deny patterns under read, which for Zed is a no-op.

Not touched, as recorded: the mcp__… ⇄ mcp:… translation, the ExtendingVec cross-scope accumulation semantics (including the factually wrong private_files rationale in the docs), sandbox_permissions (gap 5), and commands-as-skills (gap 6). Those are design-gated, so this issue stays open for them.

[dyoshikawa]

Progress update: PR #2590 landed two concrete slices of this issue. The issue stays open for the rest.

MCP permission category translation. Canonical mcp__<server>__<tool> categories were being written verbatim under agent.tool_permissions.tools, where Zed never looks them up — it addresses an MCP tool as mcp:<server>:<tool> (mcp_tool_id in crates/agent/src/tools/context_server_registry.rs). Both directions now translate, mirroring the Cursor / Kimi Code / Grok CLI / Kilo precedent, splitting only the first separator so a tool name containing __ survives the round-trip.

Inside an MCP category only the catch-all rule is emitted, as the tool's default. Pattern-scoped rules are dropped with a warning: Zed dispatches every MCP tool with a single empty input (&[String::new()], commented upstream as "MCP tools are gated only by tool id (no per-input pattern matching)"), so a pattern would be matched against "". Addresses that omit or wildcard either half are dropped too, since the lookup is exact-key on the full triple. Any canonical-spelled key an earlier version left in settings.json is swept, so it cannot resurrect stale rules on the next import.

Docs correction on private_files. The claim that Zed's array settings "replace wholesale, so an empty array would switch secret redaction off" was wrong. private_files, always_allow, always_deny and always_confirm are all Option<ExtendingVec<...>>, and ExtendingVec::merge_from calls extend_from_slice — layers accumulate rather than replace. The rationale prose is corrected and the "retracted" claim is now scoped to the file Rulesync writes rather than the effective set. Rulesync's actual behavior is unchanged.

Not covered here, still open: everything else recorded on this issue.

[dyoshikawa]

Upstream update (re-check on 2026-08-06)

Newly found releases / changes

• Zed 1.14.2 (2026-08-05, releases, blog) — OS-level agent sandboxing is now on by default for the terminal and fetch tools. Defaults forbid network access, writing outside project dirs, and writing to .git. This escalates gap 5 (agent.sandbox_permissions) from nice-to-have to near-mandatory for real setups: most configurations now need network_hosts (exact hostnames or leading *. wildcards), allow_all_hosts, write_paths, allow_fs_write_all, or allow_unsandboxed — none of which are expressible from .rulesync/permissions.jsonc (src/types/permissions.ts:892 still binds zed to the generic override schema). Concrete shape for the fix: a ZedPermissionsOverrideSchema with permission + sandbox_permissions: z.optional(z.looseObject({})) written verbatim into agent.sandbox_permissions, mirroring the Kilo/Claude Code/Codex sandbox passthrough precedent; the shared-config gateway write path in zed-permissions.ts is already in place.

Additional or changed gaps

• permissions — agent.profiles (tool-availability layer) unmapped. Profiles decide which tools exist in a thread — a separate enforcement layer from tool_permissions (a tool absent from the active profile cannot be used regardless of permissions). Per-profile keys: name, tools (per-tool booleans), enable_all_context_servers, context_servers, default_model (agent-profiles docs). Follow up Zed upstream updates: subagents via Agent Profiles (agent.profiles in settings.json) #2033 examined profiles as a subagents surface and was closed; the permissions angle — a verbatim profiles passthrough block in the same new Zed override schema, like Kimi Code's tools.enabled/tools.disabled — was not covered there. No canonicalization proposed.

Verified unchanged

Gap 6 (commands) still correctly unfiled as unsupported — .zed/commands/ and lifecycle hooks remain proposal-stage only (zed-industries/zed issue #57890, discussion #57943). Rules/ignore/mcp/skills re-verified aligned, including the PR #2590 MCP name/category translation fixes; the gated-tool list now includes skill, which rulesync's unknown-name passthrough already covers.

References

• https://zed.dev/docs/ai/sandboxing — sandbox_permissions keys + on-by-default behavior
• https://zed.dev/releases/stable — 1.14.2 (2026-08-05)
• https://zed.dev/docs/ai/agent-profiles — profiles structure