Skip to content

fix(rules): Resolve relative @ includes against source file directory#3116

Open
toniher wants to merge 6 commits into
olimorris:mainfrom
toniher:claude-include
Open

fix(rules): Resolve relative @ includes against source file directory#3116
toniher wants to merge 6 commits into
olimorris:mainfrom
toniher:claude-include

Conversation

@toniher
Copy link
Copy Markdown
Contributor

@toniher toniher commented May 16, 2026

Description

Add logic to both claude and cli parsers to resolve relative @ include paths against the directory of the source file rather than the current working directory. This allows includes to work correctly when the source file is located outside the cwd. Includes absolute paths (starting with / or ~) and cases where source_dir cannot be determined are left unchanged. Add corresponding test cases for both parsers.

Coming from discussion here: #2688 (reply in thread)

AI Usage

Claude Code with Sonnet 4.7

Prompt:

In the parser of the file `/users/bi/thermoso/remote-work/others/codecompanion.nvim.claude-include/lua/codecompanion/interactions/shared/rules/parsers/claude.lua` (with buffer number: 11), if the file is a user global one the file paths after '@' are not found if they are relative. That is: ~/.claude/CLAUDE.md can have the following content:

@RTK.md


but I want it to get the content of RTK.md that is relative to that file ~/.claude/CLAUDE.md , not from the working directory. How can it be handled in the code?

...

Can you provide a test for this new change considering recommendations from CONTRIBUTING based on Mini.test

Checklist

  • I've read the contributing guidelines and have adhered to them in this PR
  • I confirm that this PR has been majority created by me, and not AI (unless stated in the "AI Usage" section above)
  • I've run make all to ensure docs are generated, tests pass and StyLua has formatted the code
  • (optional) I've added test coverage for this fix/feature
  • (optional) I've updated the README and/or relevant docs pages

Add logic to both claude and cli parsers to resolve relative @include paths against the directory of the source file rather than the current working directory. This allows includes to work correctly when the source file is located outside the cwd. Includes absolute paths (starting with / or ~) and cases where source_dir cannot be determined are left unchanged. Add corresponding test cases for both parsers.
Copy link
Copy Markdown
Owner

@olimorris olimorris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

against the directory of the source file rather than the current working directory

Looking at the code, is this actually the case? It reads like it tries the source file dir and then tries the cwd? Otherwise, this is potentially a breaking change for users.

Comment thread lua/codecompanion/interactions/shared/rules/parsers/cli.lua
Comment thread tests/interactions/shared/rules/parsers/test_claude_parser.lua Outdated
Comment thread lua/codecompanion/interactions/shared/rules/parsers/claude.lua Outdated
@olimorris
Copy link
Copy Markdown
Owner

But absolutely solid addition to the plugin and one that I should have in from the start. We should also update the configuration page for rules to clarify how the file resolution works.

toniher added 4 commits May 19, 2026 16:11
The relative @include resolution logic has been moved to the Claude
parser and abstracted into a reusable `files.exists()` utility function.
The CLI parser no longer needs this functionality, so remove the unused
code and its associated test file.
Update the comment to more precisely describe the path resolution logic,
clarifying that non-absolute paths (those without leading / or ~) are
resolved against the source file's directory.
The rules file now documents that an INSTRUCTIONS.md file in the same directory is automatically included in the chat buffer context, without requiring a './' prefix.
@toniher
Copy link
Copy Markdown
Contributor Author

toniher commented May 19, 2026

This should be addressed! More clarity and a bit of documentation.

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