Problem
Some of my projects contain symbolic links / junction folders that point to external code directories.
These folders are not physically inside the project, but they function as part of the project because the code inside them must be searched, referenced, and edited during development.
However:
-
CodeSearch does not treat these symlink/junction folders as part of the project
-
They are excluded from search
-
Agents fail to edit files inside these directories
-
I must manually provide the absolute folder path every time
-
The agent cannot understand that these linked folders belong to the project context
This breaks the agent-assisted workflow.
Solution
The agent should automatically:
-
Detect symbolic links / junction folders inside a project
-
Treat them exactly like normal project sources
-
Resolve the actual path automatically
-
Include them in CodeSearch
-
Allow editing without requiring manual path configuration
In short:
Symlink/junction directories should be considered first-class project folders.
No manual setup should be needed.
Use Case
-
I keep shared/common code in external folders
-
Multiple projects link to these folders using junctions
-
The project actively uses and edits this linked code
-
The agent ignores these folders, so CodeSearch and Edit operations fail
This is a critical part of real-world project setups.
Priority
High — Blocking Issue
This prevents effective use of agent-powered search and code editing.
Additional Info
-
Types: Windows NTFS junction, directory symlink (
mklink /J,mklink /D) -
Other tools (VSCode, Git, Node.js, etc.) recognize and handle them normally
-
Only the agent treats them as “outside the project boundary”