Zed Unity Tools

Unity development on macOS means Rider or Visual Studio. This makes Zed a third option: open-from-Unity, correct C# editing, Unity-aware intelligence, and an AI agent that can act on the project rather than guess about it.

It is deliberately not a Rider clone. Traditional IDE integration where it has to be, AI-native where it can be.

Two layers of intelligence, split by whether Unity is running

The hard problem in Unity tooling is that half the useful information lives in the Editor's runtime and half lives in files on disk. Most tools pick one and pretend the other does not exist.

With Unity closed, a headless Roslyn and YAML daemon does static analysis: the asmdef assembly graph, find-usages across prefabs and scenes, and diagnostics — all fed to Zed over LSP. This is the part that has to work when the Editor is not open, because that is most of the time you spend reading code.

With Unity open, Unity MCP handles the live actions that genuinely need a running Editor: mutating scenes and prefabs, running tests, reading the console, executing C#. It is registered as a Zed context server rather than forked into this project — a companion dependency, not a copy.

The pieces

| Component | What it does | | --- | --- | | Unity Editor package | External-editor integration — open-from-Unity, solution generation | | Zed extension | Snippets, schemas, LSP config, commands, and the MCP registration | | Roslyn daemon | Static Unity intelligence with the Editor closed | | Roslyn analyzers | Unity-specific code warnings |

Status

v0.1, in progress: the scaffold and the foundation — open-from-Unity and reliable C# editing. macOS first; Windows and Linux are stubbed.