feat: add --memory-path CLI option to override memory directories#1100
feat: add --memory-path CLI option to override memory directories#1100EarthmanWeb wants to merge 4 commits intooraios:mainfrom
Conversation
Adds a --memory-path CLI option (and matching MCP parameter) that accepts a comma-separated list of directory paths: - First path becomes the primary write location (replaces the default '<project_root>/.serena/memories') - Additional paths are read-only sources searched when a memory is not found in the primary directory This allows using shared or team memory stores without changing the project structure, and supports multiple sources for read fallback. Changes: - MemoriesManager: add set_memory_paths(), _find_memory(), _resolve_path() - MemoriesManager: use _find_memory() in load/delete/list to include extra dirs - Project: add set_memory_paths() delegation method - SerenaAgent: accept and propagate memory_paths param - SerenaMCPFactory: accept and propagate memory_paths param - CLI: --memory-path option (comma-separated)
EarthmanWeb
force-pushed
the
feat/memory-path-option
branch
from
3d606bc to
5658947
Compare
- get_memory_file_path now returns existing path (from any dir) so writes update in-place rather than duplicating to primary - Update help/docstring to clarify write semantics
Extra memory paths passed via --memory-path can now be marked read-only by appending ':ro' (e.g. '/shared/memories:ro'). All write operations (write, edit, delete, rename) return a clear error and instruct the LLM not to retry when targeting a read-only path.
|
@EarthmanWeb with #1091 we added support for global memories. Do you think the additional flexibility through memory-path is still needed? |
This will be addressed with #1123 |
|
II can't see anything in that spec regarding read only folders, that's the
main defining factor of this PR
…On Wed, Mar 4, 2026 at 9:20 AM Dominik Jain ***@***.***> wrote:
*opcode81* left a comment (oraios/serena#1100)
<#1100 (comment)>
Read-only project roots
This will be addressed with #1123
<#1123>
—
Reply to this email directly, view it on GitHub
<#1100 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMTWGNSLQNQ62TNOHU3YFL4PA3UPAVCNFSM6AAAAACWA6R43WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSOJXHA2TANBSGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
The goal of #1123 is to allow you to move the entire |
|
You're missing the point of this PR.
It allows you to designate multiple folders, not necessarily all under the
Serena folder, in order to be able to reference documents.
I believe it's all spelled out in the PR description.
It allows you to designate multiple folders
…On Wed, Mar 4, 2026 at 6:48 PM Dominik Jain ***@***.***> wrote:
*opcode81* left a comment (oraios/serena#1100)
<#1100 (comment)>
I can't see anything in that spec regarding read only folders
#1123 <#1123> allows you to move
the entire .serena folder somewhere else entirely, thus solving the
problem of a read-only project folder. If it is read-only, move the Serena
folder outside of the project folder; all of Serena's data, including
memories, can live elsewhere.
—
Reply to this email directly, view it on GitHub
<#1100 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMTWGL2I46BKU5BNW64YCT4PC6EFAVCNFSM6AAAAACWA6R43WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMBRGAZDAMJVGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
You are missing the point of our comments. @MischaPanch pointed out that we recently added support for global memories. This addresses the first point you mentioned:
It can furthermore address the third point,
because global memories can be configured as read-only. The proposal #1123 I mentioned (which is already being worked on) specifically addresses fully read-only project folders, i.e. your second point:
You didn't answer our question as to whether these features would solve your underlying problem.
See our contribution guidelines. |
Thanks. I wasn't aware of that option and have not yet tested it. Will do so asap One thing my PR provides is listing those memories with the rest, without the /global prefix requirement though I see how that might be helpful for better original path identification. It's not clear in the notes here #1007 the configuration options for readonly for specific folders. Does readonly apply to ALL global memories when enabled? ...because I have some that I want to be able to edit outside the .serena path and some I do not. My pr addressed that by allowing a 'flag' for each new external folder that was configured. |
|
The global memories are automatically and always listed with the rest. The editing restrictions, when enabled, apply to all global memories. We have written documentation on the extended memory system here https://oraios.github.io/serena/02-usage/045_memories.html Both @opcode81 and I realize that this PR has a different functionality from what we recently merged and are working on, but there are significant overlaps. That's why we are asking whether the extensions we made are sufficient to support your workflow, maybe with small adjustments on the workflow side. If the existing features solve say 90% of the pain, it may not be worth it to add complexity for configuring additional memory containers with flags for which of them are read only and which not. This is why we are asking. We want to avoid featuritis and creating complexity that only serves very niche use cases. Serena is already very complex, maintaining it is a lot of work, and we have to be critical towards additions not only based on the code quality there but considering the maintenance and documentation overhead, as well as the configuration complexity for the users. We are not doing it to annoy you or to discourage contributions |
|
As an example on the workflow adjustment side: create links from your read-only memories containers to |
|
I agree with you, thank you for the explanation.
I am also not trying to annoy you or waste your time. When linked to a
thread instead of a PR it can get confusing. You and your colleagues know
the full context of the thread and history of the project. I do not, and
sometimes don't take enough time to research - my apologies for that.
Looking at the existing config, I would add a config possibility, based on
the work I have in this PR, which would springboard off pf yours and simply
and elegantly add an object check for:
```
edit_global_memories:
- "global/editthese"
- "global/andthese"
```
And then if it resolves true but also has data, it knows to only allow
editing for selected paths, solving both use cases
Thoughts?
…On Thu, Mar 5, 2026 at 7:16 AM Michael Panchenko ***@***.***> wrote:
*MischaPanch* left a comment (oraios/serena#1100)
<#1100 (comment)>
The global memories are automatically and always listed with the rest. The
editing restrictions, when enabled, apply to all global memories. We have
written documentation on the extended memory system here
https://oraios.github.io/serena/02-usage/045_memories.html
Both @opcode81 <https://github.com/opcode81> and I realize that this PR
has a different functionality with what we recently merged and are working
on, but there are significant overlaps. That's why we are asking whether
the extensions we made are sufficient to support you workflow, maybe with
small adjustments on the workflow side.
If the existing features solve say 90% of the pain, it may not be worth it
to add complexity for configuring additional memory containers with flags
for which of them are read only and which not. This is why we are asking,
not to annoy you.
We want to avoid featuritis and creating complexity that only serves very
niche use cases. Serena is already very complex, maintaining it is a lot of
work, and we have to be critical towards additions not only based on the
code quality there but considering the maintenance and documentation
overhead, as well as the configuration complexity for the users. We are not
doing it to annoy you or to discourage contributions
—
Reply to this email directly, view it on GitHub
<#1100 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMTWGLX73HEY6CTVTG3SID4PFV3DAVCNFSM6AAAAACWA6R43WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMBUGY2TIMZSHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Oh interesting I did not realize that you required sym links for global
memories to work. That's less than ideal.
It's not portable.
…On Thu, Mar 5, 2026 at 7:24 AM Terrance Orletsky ***@***.***> wrote:
I agree with you, thank you for the explanation.
I am also not trying to annoy you or waste your time. When linked to a
thread instead of a PR it can get confusing. You and your colleagues know
the full context of the thread and history of the project. I do not, and
sometimes don't take enough time to research - my apologies for that.
Looking at the existing config, I would add a config possibility, based on
the work I have in this PR, which would springboard off pf yours and simply
and elegantly add an object check for:
edit_global_memories:
- "global/editthese"
- "global/andthese"
And then if it resolves true but also has data, it knows to only allow
editing for selected paths, solving both use cases
Thoughts?
On Thu, Mar 5, 2026 at 7:16 AM Michael Panchenko ***@***.***>
wrote:
> *MischaPanch* left a comment (oraios/serena#1100)
> <#1100 (comment)>
>
> The global memories are automatically and always listed with the rest.
> The editing restrictions, when enabled, apply to all global memories. We
> have written documentation on the extended memory system here
> https://oraios.github.io/serena/02-usage/045_memories.html
>
> Both @opcode81 <https://github.com/opcode81> and I realize that this PR
> has a different functionality with what we recently merged and are working
> on, but there are significant overlaps. That's why we are asking whether
> the extensions we made are sufficient to support you workflow, maybe with
> small adjustments on the workflow side.
>
> If the existing features solve say 90% of the pain, it may not be worth
> it to add complexity for configuring additional memory containers with
> flags for which of them are read only and which not. This is why we are
> asking, not to annoy you.
>
> We want to avoid featuritis and creating complexity that only serves very
> niche use cases. Serena is already very complex, maintaining it is a lot of
> work, and we have to be critical towards additions not only based on the
> code quality there but considering the maintenance and documentation
> overhead, as well as the configuration complexity for the users. We are not
> doing it to annoy you or to discourage contributions
>
> —
> Reply to this email directly, view it on GitHub
> <#1100 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABMTWGLX73HEY6CTVTG3SID4PFV3DAVCNFSM6AAAAACWA6R43WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMBUGY2TIMZSHA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
I think this makes sense, it can even be made backwards compatible. In python, The configuration by the user is then edit_global_memories: true/falseOr (compatible) edit_global_memories:
path_prefix1: false
path_prefix2: truewhere for all non-configured paths we assume the current default (editing permitted). Few users would make use of this, I suppose, but it doesn't hurt. @opcode81 WDYT? |
We don't require symlinks, global memories are just any files in |
|
Right. But my PR allows for adding file paths I can add And then can set those to be read only, or not |
|
Why is it important to be able to pass paths outside of |
|
The problem it solves is when I share a project with others who have docs in another path. They don't use serena. I do. They don't want the .serena path in the main branches, and the CI excludes them. ...but they do want the shared docs retained, and I don't want to have to copy them or create symlinks to preserve the config |
Creating a symlink to |
|
From the 'problem' section of the PR, which your colleague asserts does not exist: |
Pls avoid the passive aggressive undertone. My colleague highlighted that problems should be discussed before a PR happens and not as description of a PR. |
Fair. Ok, I see your point. Thanks. With the addition of: This would work. Thanks you for your time reviewing. |
Ok, my apologies. Was referrring to: "but you didn't state what exactly your actual problem is, so we don't know why you proposed what you proposed" They did not say what you said, in regards to a discussion prior to a PR. Where would that be held? Submit issue first, THEN pr? |
|
Pls wait with implementing the config extension proposal until @opcode81 has confirmed. It extends complexity and union types are not clean and a typical source of errors, though in this particular case it might be worth doing that nevertheless |
|
I missed this in the contribution guidelines: My bad. Sorry, @opcode81 - will be more diligent in future |
|
Update to previous, while using symlinks to add global memories: The problem it solves is when I share a project with others who have docs in another path. They don't use serena. I do. They don't want the .serena path in the main branches, and the CI excludes them. Some of the external ref's inside a global path that is linked, I need to be able to define as editable, some I do not, as I do not 'own' them. If symlinks are used to share a root folder of docs with a complex inner structure and several nested hierarchies, ideally for reference I would like Serena to read that the same folder structure by creating a single top level symlink for the tree, but still be able to 'flag' internal paths within that structure as 'read only' (or at least define which are editable) The addition of: |
I have never made any such assertion.
By "what exactly your actual problem is" I meant the underlying motivation, the root of the problem. What you stated was a surface-level problem, but we need to understand, as I have pointed out, why this is perceived as a problem, i.e. get to the root of the problem, because it is frequently the case that there are other solutions to the underlying problem which do not involve finding a solution to the surface-level problem at all (much like treating a symptom in medicine). |
|
@opcode81 OK, that's fair. I didn't take the time to clearly read your comments to understand what you were asking for. I do the same with my own clients, fully understand and appreciate your socratic method. Will take better care to understand your comments in future before replying. |
|
I think "we don't know why you proposed what you proposed" is sufficiently clear. |
|
I'm going to close this and open an issue regarding extending the memory-edit-allowance configuration |
3 participants
Problem
Serena stores project memories in
<project_root>/.serena/memories/with no way to override this location at runtime. This is limiting in
several scenarios:
common knowledge should be stored in a shared location outside any
single project root
is not writable (e.g. mounted volumes, CI)
org-wide or team-wide knowledge bases
Solution
Added a
--memory-pathoption toserena-mcp-serveraccepting acomma-separated list of directory paths. Extra paths can be marked
read-only with the
:rosuffix (Docker volume convention):Behaviour:
:roto any extra path to make it read-only<project_root>/.serena/memories/if not setWrite protection:
All mutating operations (
write_memory,edit_memory,delete_memory,rename_memory) return a clear error and instruct the agent not to retry when targeting a read-only path:Implementation:
cli.py:--memory-pathoption parsed into a list;:rodocumented in help textmcp.py: propagatesmemory_pathsthroughcreate_mcp_server()→_create_serena_agent()agent.py: storesmemory_paths, callsproject.set_memory_paths()on project activationproject.py:MemoriesManagergains_readonly_dirs: set[Path],_is_readonly()helper, and write guards in all mutating methods;set_memory_paths()parses:rosuffixExamples