mirror of
https://github.com/hanzoai/dev.git
synced 2026-10-25 03:32:32 +00:00
- hanzo-tunnel v0.1.0 published to crates.io (was path dep to ../../../tunnel) - cli: tunnel + tunnel-bridge deps now optional behind `tunnel` feature flag - cli: cloud module (ZT + relay) gated with #[cfg(feature = "tunnel")] - tunnel-bridge: all hanzo_tunnel usage gated behind `tunnel` feature - CI: fix prettier by scoping JS globs, excluding symlinked CLAUDE.md - CI: format all workflows and docs with prettier - Workspace compiles clean without tunnel feature (CI default) - Local builds with `--features tunnel` still work with crates.io dep
3.3 KiB
3.3 KiB
Zed Integration
To point Zed at Every Code's (Code) ACP server, add this block to settings.json:
{
"agent_servers": {
"Code": {
"command": "npx",
"args": ["-y", "@hanzo/dev", "acp"],
},
},
}
Adjust the command or args only if you pin a different version or use a globally installed binary.
Zed prerequisites
- Zed Stable
0.201.5(released August 27, 2025) or newer adds ACP support with the Agent Panel. Update viaZed → Check for Updatesbefore wiring Every Code in. Zed’s docs call out ACP as the mechanism powering Gemini CLI and other external agents. - External agents live inside the Agent Panel (
cmd-?). Use the+button to start a new thread and pickCode(Every Code) from the external agent list. Zed runs our CLI as a subprocess over JSON‑RPC, so all prompts and diff previews stay local. - Zed installs dependencies per entry automatically. If you keep
command = "npx", Zed will download the published@hanzo/devpackage the first time you trigger the integration.
How Every Code implements ACP
- The Rust MCP server exposes ACP tools:
session/new,session/prompt, and fast interrupts viasession/cancel. These are backed by the same conversation manager that powers the TUI, so approvals, confirm guards, and sandbox policies remain intact. - Streaming
session/updatenotifications bridge Code events into Zed. You get Answer/Reasoning updates, shell command progress, approvals, and apply_patch diffs in the Zed UI without losing terminal parity. - MCP configuration stays centralized in
CODE_HOME/config.toml(Code also readsCODEX_HOME/config.tomlfor compatibility). Use[experimental_client_tools]to delegate file read/write and permission requests back to Zed when you want its UI to handle approvals. A minimal setup looks like:
[experimental_client_tools]
request_permission = { mcp_server = "zed", tool_name = "requestPermission" }
read_text_file = { mcp_server = "zed", tool_name = "readTextFile" }
write_text_file = { mcp_server = "zed", tool_name = "writeTextFile" }
Zed wires these tools automatically when you add the Code (Every Code) agent, so the identifiers above match the defaults.
- The CLI entry point (
npx @hanzo/dev acp) is a thin wrapper over the Rust binary (cargo run -p code-mcp-server -- --stdio) that ships alongside the rest of Every Code. Build-from-source workflows plug in by swappingcommandfor an absolute path to that binary.
Tips and troubleshooting
- Need to inspect the handshake? Run Zed’s
dev: open acp logscommand from the Command Palette; the log shows JSON‑RPC requests and Code replies. - If prompts hang, make sure no other process is bound to the same MCP port and that your
CODE_HOME(or legacyCODEX_HOME) points to the intended config directory. The ACP server inherits all of Every Code’s sandbox settings, so restrictive policies (e.g.,approval_policy = "never") still apply. - Zed currently skips history restores and checkpoint UI for third-party agents. Stick to the TUI if you rely on those features; ACP support is still evolving upstream.
- After a session starts, the model selector in Zed lists Every Code’s built-in presets (e.g.,
gpt-5.1-codex,gpt-5.1high/medium/low). Picking a new preset updates the running Code session immediately, so you don’t have to restart the agent to change models.