Summary
After enabling the C# extension, Zed repeatedly became unresponsive and generated macOS CPU/hang diagnostics while opening a workspace containing C# files. Disabling/removing the C# extension and its Roslyn work cache stopped the issue on the next launch.
This may still involve core Zed file-watcher behavior, but the issue only reproduced while the C# extension was installed and Roslyn was starting.
Environment
- Zed: 1.3.5 stable, build 20260520.150122
- OS: macOS 26.5 on Apple Silicon
- C# extension: 1.0.4
- Roslyn language server package observed: 5.8.0-1.26266.2
- Roslyn command observed:
Microsoft.CodeAnalysis.LanguageServer --stdio --autoLoadProjects
What Happened
- Opened a large workspace containing C# files and generated folders.
- Zed started the Roslyn language server from the C# extension.
- Zed became sluggish/unresponsive and macOS generated CPU/hang diagnostics.
- Removing the C# extension stopped the behavior.
Expected Behavior
Zed should remain responsive while the C# language server starts, even if watched paths are expensive or fail.
Diagnostic Summary
Zed log included repeated hang detection and Roslyn activity:
INFO [lsp] starting language server process ... Microsoft.CodeAnalysis.LanguageServer ... --stdio --autoLoadProjects
INFO [zed::reliability] hang detected
ERROR [project::lsp_store] Error handling response for request GetDocumentColor: Document color via roslyn failed: Missing handler for textDocument/documentColor and language C#
macOS CPU diagnostics reported high CPU during the same period:
Event: cpu usage
CPU: 90 seconds cpu time over 107 seconds (84% CPU average)
The heaviest stack repeatedly involved language-server watched paths and macOS FSEvents:
project::lsp_store::LanguageServerWatchedPathsBuilder::build
fs::RealFs::watch
fs_watcher::Watcher::add / register_existing_path
notify::fsevent::FsEventWatcher
FSEventStreamCreate
A separate hang report showed the same general file-watcher path:
LanguageServerWatchedPathsBuilder::build
RealFs::watch
FsWatcher::add
register_existing_path
FSEventStreamCreate
Workaround
Removing/disabling the C# extension and the Roslyn work cache stopped Zed from hanging/high-CPU on startup.
Privacy Note
I intentionally omitted raw logs because they contain local paths, user/machine names, and project names. I can provide additional sanitized excerpts if helpful.
Summary
After enabling the C# extension, Zed repeatedly became unresponsive and generated macOS CPU/hang diagnostics while opening a workspace containing C# files. Disabling/removing the C# extension and its Roslyn work cache stopped the issue on the next launch.
This may still involve core Zed file-watcher behavior, but the issue only reproduced while the C# extension was installed and Roslyn was starting.
Environment
Microsoft.CodeAnalysis.LanguageServer --stdio --autoLoadProjectsWhat Happened
Expected Behavior
Zed should remain responsive while the C# language server starts, even if watched paths are expensive or fail.
Diagnostic Summary
Zed log included repeated hang detection and Roslyn activity:
macOS CPU diagnostics reported high CPU during the same period:
The heaviest stack repeatedly involved language-server watched paths and macOS FSEvents:
A separate hang report showed the same general file-watcher path:
Workaround
Removing/disabling the C# extension and the Roslyn work cache stopped Zed from hanging/high-CPU on startup.
Privacy Note
I intentionally omitted raw logs because they contain local paths, user/machine names, and project names. I can provide additional sanitized excerpts if helpful.