streamable http or stdio for multiple worktrees?

[thoraxe]

The documentation isn't entirely clear to me about whether or not I'm supposed to use stdio or streamable http when using multiple worktrees.

I have many worktrees going at once with multiple claude sessions, and the codebases evolve locally until they're merged centrally. I was trying to use a single project folder (c:\blah\serena) for this overarching python project, but it's unclear what I'm actually supposed to do.

I tried streamable http but that seems like the wrong approach, because the MCP server then tried to look for content relative to the location where the streamable http server ran, and not in the local worktree folder:

ERROR 2025-12-31 16:44:53,538 [Task-5:FindSymbolTool] serena.tools.tools_base:task:274 - Error executing tool: File or directory not found: D:\Documents\rf2-ai\serena\director/battledirector/trees/subject_selection
Traceback (most recent call last):
  File "C:\Users\erikm\AppData\Local\uv\cache\archive-v0\4PSBM1RIXwN-qDMtEfMwt\Lib\site-packages\serena\tools\tools_base.py", line 249, in task
    result = apply_fn(**kwargs)
  File "C:\Users\erikm\AppData\Local\uv\cache\archive-v0\4PSBM1RIXwN-qDMtEfMwt\Lib\site-packages\serena\tools\symbol_tools.py", line 140, in apply
    symbols = symbol_retriever.find(
        name_path_pattern,
    ...<3 lines>...
        within_relative_path=relative_path,
    )
  File "C:\Users\erikm\AppData\Local\uv\cache\archive-v0\4PSBM1RIXwN-qDMtEfMwt\Lib\site-packages\serena\symbol.py", line 519, in find
    symbol_roots = lang_server.request_full_symbol_tree(within_relative_path=within_relative_path)
  File "C:\Users\erikm\AppData\Local\uv\cache\archive-v0\4PSBM1RIXwN-qDMtEfMwt\Lib\site-packages\solidlsp\ls.py", line 1122, in request_full_symbol_tree
    raise FileNotFoundError(f"File or directory not found: {within_abs_path}")
FileNotFoundError: File or directory not found: D:\Documents\rf2-ai\serena\director/battledirector/trees/subject_selection

[ketema]

I have many worktrees going at once with multiple claude sessions, and the codebases evolve locally until they're merged centrally. I was trying to use a single project folder (c:\blah\serena) for this overarching python project, but it's unclear what I'm actually supposed to do.

I tried streamable http but that seems like the wrong approach, because the MCP server then tried to look for content relative to the location where the streamable http server ran, and not in the local worktree folder:

I work in a similar manner: many projects many work-trees that supports agents working in parallel on different branches of the same project. I use a single serena http server. This causes issues because serena does not support the concept of multiple active projects via http currently. I would like to gauge interest in support for enhancing serena to be able to support this working method better.

[MischaPanch]

We have been working on an extension of Serena for that in the last months, albeit for a somewhat different use case. We call it Serena multiplexer.

@opcode81 we should keep the multiagent use case in mind for that

@ketema appreciate all your input across the various issues and PRs, will keep you updated on this topic

[ketema]

Awesome. Happy to contribute in any way needed. I actually have a draft local branch that I started, but got distracted. Happy to discuss architecture approaches, curious as to what "multi-plexer" will mean! Just let me know

[MischaPanch]

Multiplexer means it will have multiple active projects simultaneously and tools tuned for dealing with them. This was primarily for handling external dependencies and allowing a general high-level code understanding across multiple projects, but the multi-agent use case might be naturally covered through this as well. Need to think about how it best fits in - e.g. a subagent dynamically opening and registering a new project in the multiplexer and then talking to it by providing it's id to the tools could work.

We are also working on semantic search tools in that regard, that combine with the symbol based tools we already have, so the agent can query the multiple projects by just passing queries in natural language.

We will likely not open source all of this, as we need to generate some income from Serena to enable us to further work on it. But I'm happy to discuss beta testing with you or anyone interested in such a tool :)

[ketema]

Understood. I have built my own semantic search tooling and I love it, but no idea on how to monetize it lol. Good luck and I look forward to seeing what you come up with. For the open source Serena would you be open to a session based multiple project feature? Basically thats what I have done locally piggy backing off http protocol sessions. I just need to work out handling the LSPs cleanly, that is where I left off. If this would be acceptable I am happy to pick it back up and submit as a PR for open source Serena.

…

On Fri, Jan 9, 2026 at 12:26 Michael Panchenko ***@***.***> wrote: Multiplexer means it will have multiple active projects simultaneously and tools tuned for dealing with them. This was primarily for handling external dependencies and allow a general high-level code understanding across multiple projects, but the multi-agent use case might be naturally covered through this as well. Need to think about how it best fits in - e.g. a subagent dynamically opening and registering a new project in the multiplexer and then talking to it by providing it's id to the tools could work. We are also working on semantic search tools in that regard, that combine with the symbol based tools we already have, so the agent can query the multiple projects by just passing queries in natural language. We will likely not open source all of this, as we need to generate some income from Serena to enable us to further work on it. But I'm happy to discuss beta testing with you or anyone interested in such a tool :) — Reply to this email directly, view it on GitHub <#891 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7TGFFYL2KAVVBHBZMCLD4F7QETAVCNFSM6AAAAACQNMSGIKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBVGY4TGMY> . You are receiving this because you were mentioned.Message ID: ***@***.***>