What problem does this solve?
Codebase Memory currently skips symbolic links on POSIX and junctions / reparse points on Windows during repository discovery.
That default makes sense for safety and correctness: blindly following links may escape the repository root, create traversal cycles, or index the same physical tree multiple times.
However, some real-world repositories intentionally use symlinks / junctions as part of the application layout.
A concrete example is a ColdFusion application structured like this:
application/
├── client -> D:\repos\customer-client
└── core/
├── framework -> D:\repos\shared-core\framework
├── net -> D:\repos\shared-core\net
├── netbuyer -> D:\repos\shared-core\netbuyer
└── netintegration -> D:\repos\shared-core\netintegration
From the application's point of view, this is one logical codebase.
From Codebase Memory's point of view, the linked directories are currently skipped, so the resulting graph is incomplete.
Indexing the physical repositories separately is not equivalent, because it produces separate projects/databases and ordinary source-level relationships across the logical roots can no longer be represented as normal intra-project edges.
For example:
client/A.cfc
-> core/net/B.cfc
-> core/framework/C.cfc
These are not service-to-service relationships. They are normal code relationships inside what is logically one application.
In our case, separate indexing loses or weakens analysis such as:
- callers / callees across linked roots
- trace paths across client/core
- inheritance and usage across linked roots
- impact analysis for the whole logical application
- architecture understanding of the full codebase
Codebase Memory otherwise works well for this codebase, including CFML indexing, but skipping symlinked / junctioned directories prevents the graph from representing the complete application structure.
Proposed solution
Please consider making symlink / junction traversal explicitly opt-in, while preserving the current behavior as the secure default.
Conceptually, something like this could work:
follow_links = none # current/default behavior
follow_links = approved # follow only explicitly approved targets
Or possibly a slightly richer policy:
Where:
none preserves today's behaviorinternal follows links only when the canonical target remains within the allowed project boundaryapproved also permits targets explicitly approved by the user
This seems compatible with the workspace authorization model that Codebase Memory already provides around:
allow-rootallow-root --approve-manifest.cbmpathwhitelist
A possible safe traversal flow could be:
link encountered
↓
resolve canonical target
↓
check whether target is approved / allowed
↓
reject if not approved
↓
cycle / duplicate detection
↓
traverse target
The current secure behavior should remain the default.
A safe implementation would ideally also handle:
- symbolic-link cycles
- Windows junction / reparse-point cycles
- multiple logical paths resolving to the same physical target
- links pointing outside approved roots
- filesystem watching of resolved targets
- incremental indexing / artifacts involving linked files
It would also be useful, if feasible, to preserve the logical repository path in the graph while using the resolved physical path for filesystem access.
For example:
logical:
core/net/cflib/cfc/documenti/documenti.cfc
physical:
D:\shared-core\net\cflib\cfc\documenti\documenti.cfc
This would keep graph paths stable and representative of the application layout while still allowing Codebase Memory to access the actual source file.
If maintainers think an explicit multi-root / logical-workspace abstraction would be preferable to following filesystem links directly, that would also solve the underlying problem.
We would be happy to test either approach on Windows repositories that make extensive use of junctions, as well as POSIX symlink layouts.
Alternatives considered
No response
Confirmations
What problem does this solve?
Codebase Memory currently skips symbolic links on POSIX and junctions / reparse points on Windows during repository discovery.
That default makes sense for safety and correctness: blindly following links may escape the repository root, create traversal cycles, or index the same physical tree multiple times.
However, some real-world repositories intentionally use symlinks / junctions as part of the application layout.
A concrete example is a ColdFusion application structured like this:
From the application's point of view, this is one logical codebase.
From Codebase Memory's point of view, the linked directories are currently skipped, so the resulting graph is incomplete.
Indexing the physical repositories separately is not equivalent, because it produces separate projects/databases and ordinary source-level relationships across the logical roots can no longer be represented as normal intra-project edges.
For example:
These are not service-to-service relationships. They are normal code relationships inside what is logically one application.
In our case, separate indexing loses or weakens analysis such as:
Codebase Memory otherwise works well for this codebase, including CFML indexing, but skipping symlinked / junctioned directories prevents the graph from representing the complete application structure.
Proposed solution
Please consider making symlink / junction traversal explicitly opt-in, while preserving the current behavior as the secure default.
Conceptually, something like this could work:
Or possibly a slightly richer policy:
Where:
nonepreserves today's behaviorinternalfollows links only when the canonical target remains within the allowed project boundaryapprovedalso permits targets explicitly approved by the userThis seems compatible with the workspace authorization model that Codebase Memory already provides around:
allow-rootallow-root --approve-manifest.cbmpathwhitelistA possible safe traversal flow could be:
The current secure behavior should remain the default.
A safe implementation would ideally also handle:
It would also be useful, if feasible, to preserve the logical repository path in the graph while using the resolved physical path for filesystem access.
For example:
This would keep graph paths stable and representative of the application layout while still allowing Codebase Memory to access the actual source file.
If maintainers think an explicit multi-root / logical-workspace abstraction would be preferable to following filesystem links directly, that would also solve the underlying problem.
We would be happy to test either approach on Windows repositories that make extensive use of junctions, as well as POSIX symlink layouts.
Alternatives considered
No response
Confirmations