Skip to content

Fix EditMemoryTool: remove ReplaceContentTool dependency#1096

Closed
EarthmanWeb wants to merge 2 commits intooraios:mainfrom
EarthmanWeb:fix/replace-content-tool-no-lsp
Closed

Fix EditMemoryTool: remove ReplaceContentTool dependency#1096
EarthmanWeb wants to merge 2 commits intooraios:mainfrom
EarthmanWeb:fix/replace-content-tool-no-lsp

Conversation

@EarthmanWeb
Copy link

Problem

EditMemoryTool.apply() delegates to ReplaceContentTool to perform
its text replacement. This creates an indirect dependency on the LSP
layer: ReplaceContentTool routes through the language server to
locate and modify files, which is unnecessary and incorrect for memory
files — memory files live in .serena/memories/ and are not part of
the indexed project source.

In contexts where the LSP is not active or the memory path is outside
the project root, this causes EditMemoryTool to fail entirely.

Fix

Replaced the ReplaceContentTool delegation in memory_tools.py with
direct file I/O using Python's standard re module:

  • Reads the memory file directly via _find_memory()
  • Performs literal or regex replacement inline
  • Writes the result back — no LSP involvement

Behaviour is identical from the caller's perspective: supports both
"literal" and "regex" modes, returns a descriptive error if the
needle/pattern is not found.

Example

Before (broken in non-LSP contexts):

# EditMemoryTool.apply() called ReplaceContentTool which required an
# active language server and a path relative to the project root.
# Memory files outside the project root would raise an exception.

After:

memory_path = self.memories_manager._find_memory(memory_name)
content = memory_path.read_text(encoding="utf-8")
new_content = content.replace(needle, repl, 1)  # literal mode
memory_path.write_text(new_content, encoding="utf-8")

EditMemoryTool previously delegated to ReplaceContentTool which required
a language server. Replace with a direct file read/write implementation
using Python's re module, eliminating the LSP dependency for memory edits.
@opcode81
Copy link
Contributor

This is already changed in #1091 (to be merged soon), where we factored out the replacement logic to a separate utility class.

@opcode81 opcode81 closed this Feb 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants