agent-joule/PRIVACY_HARDENING.md

agent-zed — Privacy Hardening

agent-zed is a private, no-phone-home fork of Zed. It drives vendors' own logged-in agent CLIs (Claude Code, Gemini) over ACP plus a local vLLM backend. It must never establish a Zed identity, send telemetry, upload crashes, check for updates, or make any unprompted network call to Zed-operated (or Zed-adjacent) infrastructure.

This document records what was removed/neutralized and how it was verified.

Threat model / goal

• No automatic sign-in; no Zed account is ever established.
• No telemetry, analytics, or usage events leave the machine.
• No crash/minidump upload.
• No auto-update or contact with release servers.
• No unprompted startup fetches to Zed-operated endpoints.
• Expected, allowed traffic: the federated agent processes the user explicitly drives (e.g. npx ACP agents) and the local vLLM backend on localhost. These are the vendor's processes, not agent-zed phoning home.

Changes

A — Sign-in removed

• crates/zed/src/main.rs: authenticate() is a no-op — no automatic sign-in/connect at startup, so no Zed identity is established (this was the real phone-home).
• crates/title_bar: removed the Sign In button + now-unused bindings.
• crates/onboarding: removed the Zed-cloud "Zed Agent" promo + SignIn action. The dangling onboarding::SignIn keybindings were also removed from the three default keymaps (a removed action left bound = startup keymap-validation panic).
• The client crate stays compiled but signed-out; collab/CRDT is retained for later self-hosting against a non-Zed server.

B — Auto-update removed entirely

Updates are a wholesale uninstall + reinstall; there is no in-app updater.

• Deleted the auto_update, auto_update_ui, and auto_update_helper crates and all usages (menus, title-bar affordance, activity indicator, init).
• This closed a residual egress that the earlier poll-neuter missed: auto_update still contained live calls to Zed release servers (download_remote_server_release / get_release_asset), reachable via "Check for Updates" and the SSH remote-server download path.
• remote_connection: remote-server auto-download is stubbed to a clear "disabled in agent-zed" error instead of silently fetching from Zed.
• Windows packaging was updated to match: script/bundle-windows.ps1 no longer builds/copies/signs auto_update_helper, and zed.iss drops the {app}\tools and {app}\updates directories (auto-update installer artifacts).

C — Telemetry neutralized

• crates/client/src/telemetry.rs: send_event() is a no-op, so every telemetry::event! call site across the tree is inert with a single edit. Nothing is queued, recorded, or sent.

D — Crash upload disabled

• MINIDUMP_ENDPOINT is forced to None (ignores build/runtime env), so the upload paths in reliability.rs are unreachable. Local minidump capture is unaffected. (Runtime log confirms: "Minidump endpoint not set".)
• RefreshLlmTokenListener is inert (no sign-in event to trigger a Zed cloud token refresh).

E — ACP agent-registry auto-fetch disabled

The federation feature auto-fetched the ACP agent registry from cdn.agentclientprotocol.com at startup (registry index + icons). This is not Zed telemetry, but it is an unprompted launch-time request to Zed-adjacent infrastructure — exactly the egress this build avoids.

• crates/project/src/agent_registry_store.rs: removed the startup auto-refresh in init_global, and made refresh_if_stale() a no-op (this was the path that actually fired, via agent-settings load and registry-agent connect).
• The registry still loads from the on-disk cache, and the explicit, user-initiated refresh() (e.g. opening the Agent Registry page) still works. Only the automatic, staleness-driven fetch is gone.

F — Egress backstop

Belt-and-suspenders: even if some code path survived the removals above, it cannot reach a Zed host.

• crates/http_client/src/http_client.rs: the four Zed-host URL builders (build_zed_api_url, build_zed_cloud_url, build_zed_cloud_url_with_query, build_zed_llm_url) now bail! instead of returning a URL. Any surviving caller fails loudly rather than contacting api.zed.dev / cloud.zed.dev / llm.zed.dev.

Extensions

• assets/settings/default.json: auto_install_extensions is empty by default (was {"html": true}), so the extension registry/CDN is not contacted at startup. Users opt in to extensions explicitly.

Verification

Method: launch the built agent-zed against a fresh --user-data-dir, then observe outbound connections with lsof -nP -i -p <pid> and capture TLS SNI hostnames with tshark -i en0 -Y 'tls.handshake.type == 1' (Wireshark's ChmodBPF grants capture access without sudo). IP-based inference is unreliable here because Zed and the ACP CDN both sit behind Cloudflare anycast; SNI is authoritative.

Findings across the hardening passes:

• Zero connections to *.zed.dev (Zed's own infra) at any point.
• The one persistent startup egress observed (~36 connections) was conclusively identified by SNI as cdn.agentclientprotocol.com — the ACP registry fetch, fixed in E above.
• After E: agent-zed makes zero outbound connections at idle startup (0 established across repeated samples; no cdn.agentclientprotocol.com, no *.zed.dev in the SNI capture). Startup is network-silent.

Re-run the check after any change touching networking:

cargo build --bin agent-zed
tshark -i en0 -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e tls.handshake.extensions_server_name -a duration:26 | sort | uniq -c &
./target/debug/agent-zed --user-data-dir /tmp/azed-check .
# expect: no agent-zed connections to *.zed.dev or *.agentclientprotocol.com