You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The workspace Open project folder control supports VS Code, Terminal, and File Explorer only. Users who edit in Zed must open the project folder manually after agents change files.
Proposal
Add Zed as an optional open-with target (same product surface as VS Code):
Detect install (zed on PATH and/or platform app/CLI paths; same idea as VS Code detection)
Show the option only when installed
Open the conversation workspace folder via existing shell APIs
(POST /api/shell/check-tool-installed, POST /api/shell/open-folder-with with tool: "zed")
Implementation sketch (atomic PRs)
AionCore — extend ToolType + ShellService detect/open for Zed
AionUi — WorkspaceOpenButton + i18n + IPC union type
I am happy to open draft PRs linked to this issue.
Non-goals
Not adding Zed as an ACP agent (Zed is an ACP client, like AionUi)
Not embedding Zed or changing the agent selector
Not making Zed the default editor
Not implementing a full custom-editor registry in this first change
Design question for maintainers
Is Zed-only parity acceptable for this PR series?
If you would rather invest in a generic open-with list (VS Code, Zed, Cursor, user-defined command) instead of one-off editor keys, say so and we can:
either reshape this work into that design, or
ship Zed-only now and treat generic open-list as a follow-up issue.
Default plan if no preference: ship Zed-only (smallest change, mirrors current VS Code path).
Related
Prior shell/open-workspace work on Windows: fix(shell): spawn EINVAL when opening workspace folder on Windows #2210 (fix(shell): spawn EINVAL when opening workspace folder on Windows) — we will follow the robust spawn/detection patterns already in AionCore so Zed on Windows does not reintroduce .cmd / spawn EINVAL issues.
No existing feature request for “Open in Zed” found at time of writing (2026-07-24).
Why this fits AionUi
AionUi is the cowork host; the user’s IDE is where they deeply navigate code. “Open in VS Code” already encodes that handoff. Zed is the same category of user preference—not a competing agent product.
Environment notes (for implementers)
Desktop Electron only (button already hidden in WebUI)
macOS / Windows / Linux best-effort detection; hide when not installed
Problem
The workspace Open project folder control supports VS Code, Terminal, and File Explorer only. Users who edit in Zed must open the project folder manually after agents change files.
Proposal
Add Zed as an optional open-with target (same product surface as VS Code):
zedon PATH and/or platform app/CLI paths; same idea as VS Code detection)(
POST /api/shell/check-tool-installed,POST /api/shell/open-folder-withwithtool: "zed")Implementation sketch (atomic PRs)
ToolType+ShellServicedetect/open for ZedWorkspaceOpenButton+ i18n + IPC union typeI am happy to open draft PRs linked to this issue.
Non-goals
Design question for maintainers
Is Zed-only parity acceptable for this PR series?
If you would rather invest in a generic open-with list (VS Code, Zed, Cursor, user-defined command) instead of one-off editor keys, say so and we can:
Default plan if no preference: ship Zed-only (smallest change, mirrors current VS Code path).
Related
fix(shell): spawn EINVAL when opening workspace folder on Windows) — we will follow the robust spawn/detection patterns already in AionCore so Zed on Windows does not reintroduce.cmd/spawn EINVALissues.Why this fits AionUi
AionUi is the cowork host; the user’s IDE is where they deeply navigate code. “Open in VS Code” already encodes that handoff. Zed is the same category of user preference—not a competing agent product.
Environment notes (for implementers)