Improve monorepo support by separating memory and LSP context

[arikon]

Is your feature request related to a problem? Please describe.
Yes. Serena is hard to use in very large monorepos where many logically separate projects live in the same repository, but parts of the codebase are still connected through dependencies.

In this setup, I want LSPs to run from the monorepo root so navigation, references, and dependency resolution work across the whole repository. At the same time, I want .serena/memory to stay project-specific, so each logical project can have its own isolated memory/context.

Right now, activate_project switches both:

• the memory context, and
• the code/LSP root.

That makes it difficult to use Serena effectively in large monorepos, because switching to a project also narrows the LSP scope to that project root.

Describe the solution you'd like
It would be great to decouple memory context from code/LSP context.

A few possible ways to support this:

• Add a configuration option that changes activate_project so it only switches memory, while keeping the current code/LSP root unchanged.
• Or add separate commands for switching only the memory context without affecting LSPs / code indexing scope.

This would make it possible to:

• run LSPs from the monorepo root,
• keep full cross-project code intelligence,
• and still have separate .serena/memory contexts for individual projects.

Describe alternatives you've considered
The main alternative is using activate_project as-is, but that does not work well because it switches both memory and LSP context together.

Another option is to use a single shared memory for the whole monorepo, but in practice that becomes too noisy and mixes context from unrelated projects.

Additional context
This is mainly relevant for very large enterprise monorepos containing many unrelated codebases in one repository.

In that kind of setup:

• project boundaries are logical, not repo-based,
• dependencies can span multiple projects,
• LSPs need repo-wide visibility,
• but memory should stay isolated per project.

A feature that allows switching memory independently from LSP/code context would make Serena much more usable in this scenario.

[opcode81]

You can use the query_project tool to read memories from the subprojects, provided that the subprojects are also Serena projects already (which seems to be the case).
You would only need to instruct the LLM to specifically do this.

Would that be a good solution?

PS: Note that for reading memories, you do not need the project server/JetBrains IDE to be open for the other projects.

[arikon]

@opcode81 I don't only want to read memories from different projects, but also to write them.
I want to open single monorepo workspace to work on many linked projects together, which have separate Serena memory banks, but LSP running from the root of monorepo.

I'm not sure how to get it to work with query_project tool.

[opcode81]

While the query_project tool currently allows only read-only tools to be executed, this is essentially an artificial restriction. For the most part, we only need to remove the respective restriction to allow arbitrary executions in other projects.

We'll need to think about how this would need to be configured - or if it's perhaps desirable to not restrict this to read-only executions in general. Perhaps a flag query_project_write, which can be set per project, would make sense.