fix(memory): preserve memory file permissions across atomic save

[BlueX888]

Description

KnowledgeGraphManager.saveGraph() persists the graph by writing a temporary file and renaming it over memory.jsonl. The rename replaces the target's inode with the temp file's, and the temp file was created under the process umask (0666 & ~umask), so permission bits an operator set on the memory file were discarded on the next mutation and the file came back 0644. This restores the original bits after a successful rename.

Server Details

• Server: memory
• Changes to: knowledge graph persistence (src/memory/index.ts)

Motivation and Context

Fixes #4827.

Root cause — src/memory/index.ts:193-194 before this change:

await fs.writeFile(tempFilePath, lines.join("\n") + "\n");
await fs.rename(tempFilePath, this.memoryFilePath);

rename(2) replaces the target inode with the temp file's inode. The temp file is created with the process umask applied, so the original file's mode is discarded with its inode and nothing restores it. saveGraph feeds every mutation (create_entities, add_observations, delete_*), so all of them loosened the file.

This is a regression from #4642 (642a911): the previous await fs.writeFile(this.memoryFilePath, lines.join("\n")) preserved the mode of an existing file.

The repository already settled the contract for this exact write pattern. src/filesystem/lib.ts:231 restores origStats.mode & 0o777 after its temp-file + rename, merged as #4115 — "The atomic write pattern (write temp file + rename) replaces the original inode, causing the new file to have default 0644 permissions regardless of what the original file had." This change applies the same restore to the memory server.

Changes

• src/memory/index.ts — saveGraph() stats the memory file before the write, tolerating ENOENT for a file that does not exist yet (nothing to preserve), and restores mode & 0o777 after a successful rename with a best-effort chmod. The data is already durable at that point, so a chmod failure does not fail the save — the same trade-off the filesystem server makes.
• src/memory/__tests__/file-permissions.test.ts — new regression test covering 0600 and 0640 across a mutation, and asserting the mutation is still persisted.

How Has This Been Tested?

The new test fails on the unpatched tree and passes with the fix. No LLM client was used.

cd src/memory

# unpatched (origin/main d73f99e) — fails
npx vitest run __tests__/file-permissions.test.ts
#   AssertionError: mode after a save: expected '644' to be '600'
#   AssertionError: mode after a save: expected '644' to be '640'
#   Test Files  1 failed (1)
#        Tests  2 failed (2)

# patched
npx vitest run __tests__/file-permissions.test.ts
#   Test Files  1 passed (1)
#        Tests  2 passed (2)

# full module suite (CI runs `npm test --if-present`)
npm test
#   Test Files  8 passed (8)
#        Tests  89 passed (89)

# typecheck + build (CI runs `npm run build`)
npm run build
# exit 0

Breaking Changes

None. A file that does not exist yet is created exactly as before, under the process umask.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

Scope note: this change preserves the permission bits of an existing memory file, including a read-only one, but it does not make the write itself fail on a 0444 target. rename(2) only needs a writable containing directory, so the rename succeeds where the pre-#4642 fs.writeFile raised EACCES. Rejecting that write would be a separate behaviour change — it would make saveGraph fail where it currently does not — so it is not included here. Happy to add it if you want that contract restored.

The open PR #4819 touches src/memory/index.ts in addObservations (around line 250), well away from saveGraph; the two should not conflict.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.