Serena's C# setup has two related discoverability issues around ignored_paths: large repositories can be expensive to diagnose when Roslyn opens unrelated nested projects, and common unquoted gitignore-style globs can crash Serena startup with a raw YAML error.
Environment
- OS: Windows
- Serena package:
serena-agent 1.1.2
- C# backend: LSP
- Roslyn language server:
roslyn-language-server.win-x64.5.5.0-2.26078.4
- Client: Codex Desktop using Serena as a stdio MCP server
- Serena command shape:
serena.exe start-mcp-server --context=codex --project <repo> --enable-web-dashboard false --open-web-dashboard false
Note: serena --version does not appear to be supported, so the Serena version above was read from the installed Python package metadata.
What happened
While investigating why Serena appeared "heavy", the process tree showed that most memory was not the small serena.exe process itself, but the child Python process and the Roslyn language server.
The Roslyn server opened unrelated nested .csproj files from example/worktree-like directories under the repository. Redacted examples from the Serena log:
LSP: [project/open] [LanguageServerProjectLoader] Warning while loading <repo>/examples/.../CompileCommandsJson.csproj: ...
LSP: [project/open] [LanguageServerProjectLoader] Error while loading <repo>/examples/.../NVAccess.NVDA.csproj: ...
error NETSDK1045: current .NET SDK does not support targeting .NET 10.0 [... <repo>/examples/.../GenerateZw.csproj]
This made the memory usage and diagnostics look related to the active project, while the expensive work was coming from nested projects that were not relevant to the current workspace.
The workaround was to add project-level ignored_paths, for example:
ignored_paths:
- "examples/**"
- ".worktrees/**"
- "**/bin/**"
- "**/obj/**"
However, the first attempt used normal gitignore-looking patterns without quotes:
ignored_paths:
- examples/**
- .worktrees/**
- **/bin/**
- **/obj/**
That caused Serena to fail at startup with a raw YAML parser error:
ERROR Fatal exception: found undefined alias '**/bin/**'
in "<project>/.serena/project.yml", line 63, column 3
This is technically valid YAML behavior because * starts an alias, but it is an easy trap when the config comments say the syntax is the same as gitignore and users naturally write **/bin/**.
Why this is hard to discover
- Users may only see that Serena consumes a lot of memory, not that the C# language server is indexing unrelated nested projects.
- The generated
.serena/project.yml leaves ignored_paths: [], but does not show quoted glob examples.
- The startup failure for
**/... looks like an internal crash rather than a config validation problem.
Additional context
In Codex, stdio MCP servers may be started when a project/thread is resumed or when server status is checked, before the user explicitly calls a Serena tool. This is not the root cause, but it makes the startup cost visible earlier.
Suggested improvements
- Add quoted examples for common ignored paths in the generated
project.yml, especially patterns that start with *, such as "**/bin/**" and "**/obj/**".
- Validate
project.yml and report a friendlier message when YAML aliases are accidentally used in ignored_paths.
- Consider documenting a C# / Roslyn troubleshooting section that explains how nested
.csproj discovery affects memory and diagnostics.
- Clarify whether
ignored_paths are expected to affect C# language server project discovery, and if so, how early they are applied.
Expected behavior
Users configuring Serena for a large C# repository should have an obvious, safe path to exclude nested examples, worktrees, and build output directories, and a config typo should not look like an unexplained Serena crash.
Serena's C# setup has two related discoverability issues around
ignored_paths: large repositories can be expensive to diagnose when Roslyn opens unrelated nested projects, and common unquoted gitignore-style globs can crash Serena startup with a raw YAML error.Environment
serena-agent 1.1.2roslyn-language-server.win-x64.5.5.0-2.26078.4Note:
serena --versiondoes not appear to be supported, so the Serena version above was read from the installed Python package metadata.What happened
While investigating why Serena appeared "heavy", the process tree showed that most memory was not the small
serena.exeprocess itself, but the child Python process and the Roslyn language server.The Roslyn server opened unrelated nested
.csprojfiles from example/worktree-like directories under the repository. Redacted examples from the Serena log:This made the memory usage and diagnostics look related to the active project, while the expensive work was coming from nested projects that were not relevant to the current workspace.
The workaround was to add project-level
ignored_paths, for example:However, the first attempt used normal gitignore-looking patterns without quotes:
That caused Serena to fail at startup with a raw YAML parser error:
This is technically valid YAML behavior because
*starts an alias, but it is an easy trap when the config comments say the syntax is the same as gitignore and users naturally write**/bin/**.Why this is hard to discover
.serena/project.ymlleavesignored_paths: [], but does not show quoted glob examples.**/...looks like an internal crash rather than a config validation problem.Additional context
In Codex, stdio MCP servers may be started when a project/thread is resumed or when server status is checked, before the user explicitly calls a Serena tool. This is not the root cause, but it makes the startup cost visible earlier.
Suggested improvements
project.yml, especially patterns that start with*, such as"**/bin/**"and"**/obj/**".project.ymland report a friendlier message when YAML aliases are accidentally used inignored_paths..csprojdiscovery affects memory and diagnostics.ignored_pathsare expected to affect C# language server project discovery, and if so, how early they are applied.Expected behavior
Users configuring Serena for a large C# repository should have an obvious, safe path to exclude nested examples, worktrees, and build output directories, and a config typo should not look like an unexplained Serena crash.