Managing Serena across multiple projects and worktrees without turning MCP config into a project of its own

[xizhibei]

Serena is stateful in a useful way: it has a project root, language-server state, indexes, memories, and project-specific behavior. That is exactly what makes it valuable for coding agents.

The hard part shows up when you use more than one agent/client/project:

• Claude Code in one repo
• Codex in another
• Cursor attached to the same repo
• spawned agents in git worktrees
• multiple sessions that should share one Serena instance for the same project, but should not share across different projects

Serena's official docs already describe the right primitives:

• same project + multiple agents: use a shared streamable HTTP Serena instance
• different projects + multiple agents: use separate Serena instances
• cross-project reading: use query_project
• one agent editing across several folders: make a combined/monorepo Serena project when that is actually the intended code root

The part that still gets messy is client configuration. Most MCP clients want static JSON, but the correct Serena config is often dynamic: it depends on the current repo, worktree, client, or session.

That is the runtime/config problem 1MCP template servers are meant to solve.

Instead of copying Serena config per client or per repo, define it once as a template:

{
  "mcpTemplates": {
    "serena": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/oraios/serena",
        "serena",
        "start-mcp-server",
        "--project",
        "{{project.path}}",
        "--context",
        "claude-code"
      ],
      "tags": ["serena", "semantic", "project"]
    }
  }
}

Then the runtime can make the instance decision from context:

• same rendered project/config -> reuse the same Serena instance
• different rendered project/config -> create/use a separate Serena instance
• different client -> render a different --context if needed

This does not replace Serena's project model. It keeps Serena project-scoped and uses 1MCP for the outer routing/lifecycle/config problem.

The cases where this helps most:

• many repos with one global agent setup
• Claude/Codex/Cursor sharing MCP servers
• git worktrees where startup CWD can be misleading
• avoiding duplicate Serena/LSP processes for the same project
• keeping different projects isolated without hand-writing config per project

1MCP Serena docs: https://docs.1mcp.app/guide/integrations/serena
Serena workflow docs: https://oraios.github.io/serena/02-usage/040_workflow.html