fix(memory): support symlinks in memory file discovery #2961

kira-ariaki · 2026-01-27T21:18:25Z

Summary

walkDir now follows symbolic links using fs.stat() to determine if the target is a file or directory. This enables:

Symlinked markdown files inside memory/ to be indexed
Symlinked directories inside memory/ to be traversed
Graceful handling of dangling symlinks (silently skipped)

Problem

The current walkDir implementation uses dirent.isFile() to check if an entry is a file. However, for symbolic links, dirent.isFile() returns false (the dirent type is "symbolic-link", not "file"), causing symlinks to be excluded from memory search indexing.

This is especially relevant for:

Users who symlink external note directories into memory/
The proposed workspace setup in fix: Create memory directory and symlink identity files during workspace setup #2884 that creates symlinks for identity files

Solution

For entries that are symbolic links, we now call fs.stat() (which follows symlinks) to determine the actual target type:

if (entry.isSymbolicLink()) {
  try {
    const stat = await fs.stat(full);
    isDir = stat.isDirectory();
    isFile = stat.isFile();
  } catch {
    // Dangling symlink or inaccessible target - skip silently
    continue;
  }
}

Cross-platform notes

Linux/macOS: Works as expected
Windows: Creating symlinks may require elevated permissions, but reading existing symlinks works without special privileges
Dangling symlinks are gracefully skipped (no errors thrown)

Test plan

Added test: symlinked markdown files are discovered
Added test: files inside symlinked directories are discovered
Added test: dangling symlinks are skipped gracefully
Existing tests unaffected

Related: #2884

walkDir now follows symbolic links using fs.stat() to determine if the target is a file or directory. This enables: - Symlinked markdown files inside memory/ to be indexed - Symlinked directories inside memory/ to be traversed - Graceful handling of dangling symlinks (silently skipped) Fixes an issue where dirent.isFile() returned false for symlinks, causing them to be excluded from memory search indexing. Cross-platform notes: - Works on Linux/macOS/Windows (symlink support varies by platform) - Windows may require elevated permissions to create symlinks, but reading existing symlinks works without special privileges

gumadeiras · 2026-01-27T21:47:07Z

Symlinking outside of the workspace could introduce a number of problems in terms of security, recurrence, and scoping. Would it maybe be better to add support for custom search paths and force the user to add them manually?

Adding explicit, user‑configured search paths is safer than automatically following arbitrary symlinks

kira-ariaki · 2026-01-27T21:53:53Z

Thanks for the feedback! You raise a valid point about security considerations.

A few thoughts:

User intent is explicit — Symlinks inside memory/ are created by the user themselves, so following them respects an intentional configuration choice (similar to how git follows symlinks in the working tree).
Scoped to workspace — We only follow symlinks discovered inside the existing memory/ directory, not arbitrary paths. The user must deliberately place a symlink there.
Consistency with fix: Create memory directory and symlink identity files during workspace setup #2884 — The proposed workspace setup in fix: Create memory directory and symlink identity files during workspace setup #2884 creates symlinks for identity files. Without this fix, those symlinks would be silently ignored.
Recursion safety — fs.stat() follows the symlink to its final target, so circular symlinks would fail with ELOOP and be gracefully skipped (same as dangling symlinks).

That said, I agree that explicit search paths could be a nice enhancement for power users who want more control. Would you prefer that as a follow-up PR, or should we gate symlink traversal behind a config flag (e.g., memorySearch.followSymlinks: true)?

gumadeiras · 2026-01-28T17:30:11Z

User intent is explicit — Symlinks inside memory/ are created by the user themselves, so following them respects an intentional configuration choice (similar to how git follows symlinks in the working tree).

Yes, but it can lead to unwanted situations where the user thinks it’s symlinking a single directory, but that directory could also contain symlinks, resulting in unwanted/insecure behavior. Or a simple attack where a symlink is created in the workspace to give it access to things outside of the workspace. We could think about hierarchical symlinking in terms of allowing depth=1, but that could become very ad hoc; I think having an explicit specification would be safer and simpler for a first pass at this feature

Let's put a pin on the symlinking for a couple of days and i'll get back on this after we've discussed implications

Could you do a follow up PR for explicit search paths? thanks!

@gumadeiras

Add a `paths` option to `memorySearch` config, allowing users to explicitly specify additional directories or files to include in memory search. Follow-up to openclaw#2961 as suggested by @gumadeiras — instead of auto-following symlinks (which has security implications), users can now explicitly declare additional search paths. - Add `memorySearch.paths` config option (array of strings) - Paths can be absolute or relative (resolved from workspace) - Directories are recursively scanned for `.md` files - Single `.md` files can also be specified - Paths from defaults and agent overrides are merged - Added 4 test cases for listMemoryFiles

@gumadeiras

Add a `paths` option to `memorySearch` config, allowing users to explicitly specify additional directories or files to include in memory search. Follow-up to moltbot#2961 as suggested by @gumadeiras — instead of auto-following symlinks (which has security implications), users can now explicitly declare additional search paths. - Add `memorySearch.paths` config option (array of strings) - Paths can be absolute or relative (resolved from workspace) - Directories are recursively scanned for `.md` files - Single `.md` files can also be specified - Paths from defaults and agent overrides are merged - Added 4 test cases for listMemoryFiles

@gumadeiras

Add a `paths` option to `memorySearch` config, allowing users to explicitly specify additional directories or files to include in memory search. Follow-up to #2961 as suggested by @gumadeiras — instead of auto-following symlinks (which has security implications), users can now explicitly declare additional search paths. - Add `memorySearch.paths` config option (array of strings) - Paths can be absolute or relative (resolved from workspace) - Directories are recursively scanned for `.md` files - Single `.md` files can also be specified - Paths from defaults and agent overrides are merged - Added 4 test cases for listMemoryFiles

@gumadeiras

Add a `paths` option to `memorySearch` config, allowing users to explicitly specify additional directories or files to include in memory search. Follow-up to openclaw#2961 as suggested by @gumadeiras — instead of auto-following symlinks (which has security implications), users can now explicitly declare additional search paths. - Add `memorySearch.paths` config option (array of strings) - Paths can be absolute or relative (resolved from workspace) - Directories are recursively scanned for `.md` files - Single `.md` files can also be specified - Paths from defaults and agent overrides are merged - Added 4 test cases for listMemoryFiles

@gumadeiras

Add a `paths` option to `memorySearch` config, allowing users to explicitly specify additional directories or files to include in memory search. Follow-up to openclaw#2961 as suggested by @gumadeiras — instead of auto-following symlinks (which has security implications), users can now explicitly declare additional search paths. - Add `memorySearch.paths` config option (array of strings) - Paths can be absolute or relative (resolved from workspace) - Directories are recursively scanned for `.md` files - Single `.md` files can also be specified - Paths from defaults and agent overrides are merged - Added 4 test cases for listMemoryFiles

@gumadeiras

Add a `paths` option to `memorySearch` config, allowing users to explicitly specify additional directories or files to include in memory search. Follow-up to openclaw#2961 as suggested by @gumadeiras — instead of auto-following symlinks (which has security implications), users can now explicitly declare additional search paths. - Add `memorySearch.paths` config option (array of strings) - Paths can be absolute or relative (resolved from workspace) - Directories are recursively scanned for `.md` files - Single `.md` files can also be specified - Paths from defaults and agent overrides are merged - Added 4 test cases for listMemoryFiles

mollywires mentioned this pull request Jan 28, 2026

fix(plugins): follow symlinks in plugin and hook discovery #3564

Open

2 tasks

kira-ariaki mentioned this pull request Jan 28, 2026

feat(memory): add explicit paths config for memory search #3600

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(memory): support symlinks in memory file discovery #2961

fix(memory): support symlinks in memory file discovery #2961

kira-ariaki commented Jan 27, 2026

Uh oh!

gumadeiras commented Jan 27, 2026

Uh oh!

kira-ariaki commented Jan 27, 2026

Uh oh!

gumadeiras commented Jan 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

fix(memory): support symlinks in memory file discovery #2961

Are you sure you want to change the base?

fix(memory): support symlinks in memory file discovery #2961

Conversation

kira-ariaki commented Jan 27, 2026

Summary

Problem

Solution

Cross-platform notes

Test plan

Uh oh!

gumadeiras commented Jan 27, 2026

Uh oh!

kira-ariaki commented Jan 27, 2026

Uh oh!

gumadeiras commented Jan 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants