Zed opens source folders as projects and combines editing, language tooling, terminals, tasks and debugging in one workspace. A project can stay on the local computer, run against another machine through SSH or become a shared session for collaborators. These modes move different work. A remote project keeps the visible interface locally while its source files and development processes remain on the remote host.
Remote development splits the workspace
Zed invokes SSH and installs a matching server under the remote user’s .zed_server directory. Source files, terminals, tasks and language servers run there. The local computer keeps the interface, Tree-sitter state, unsaved changes and recent-project metadata.
The remote host must run a supported macOS or Linux system; Windows does not serve as a supported remote host in this workflow. Very large directories also create trouble. The documentation recommends opening a smaller subproject when a tree reaches roughly one hundred thousand files instead of asking Zed to index the entire parent directory.
A remote terminal cannot use the zed command to open one of its files directly in the local client. The terminal and editor share the remote project context, but they do not collapse into one desktop process. The file must be opened through the project tree or another supported editor action.
Tasks turn editor context into shell commands
A task runs a shell command and can interpolate the current file, selected text or symbol. Project task definitions make repeatable build and test actions available to everyone who opens that project configuration. The interpolated value comes from the active editor context, so running the same task from another file can produce another command.
Debug sessions use launch or attach configurations. Zed stores project definitions in .zed/debug.json, while global definitions apply outside one repository. The debugger follows the Debug Adapter Protocol; it still depends on a suitable adapter and runtime for the target language.
A shared project remains on the host machine
During collaboration, one participant hosts the project. Invited people can edit, search and use language tooling when the host grants write access. Their edits still operate against the project hosted on that participant’s machine. Sharing does not upload the repository into an independent cloud workspace that survives the host’s machine or session. Closing the hosted project therefore changes what collaborators can reach.
Channels can hold shared projects, voice conversations and persistent notes. Joining a channel may enable the microphone automatically when the operating system already granted permission, unless the user enables mute-on-join. That behavior makes the channel state relevant before entry, particularly when the user only intends to read notes or inspect a project. The persistent note belongs to the channel rather than to a local source file in the hosted repository.
