Conflict with autochdir

[gitsang]

When I turn on vim.opt.autochdir = true, the work dir of codecompanion also changes accordingly, which causes errors when llm uses relative paths (because llm doesn't know that the work dir has changed). Has anyone encountered this issue, and how did you solve it? (Besides turning off this option)

[olimorris]

A design feature of CodeCompanion is that only relative paths are sent to the LLM.

[gitsang]

I know, precisely because of this, when I switch buffers, if the file path changes, then the query or execution path for CodeCompanion will no longer be correct.

This is not a problem with CodeCompanion, but what I want to ask is whether there is a way to separate CodeCompanion's work directory(for tools use) from vim's work directory so that it is not affected by vim's path changes.

For example, when I use Claude Code, it always stays fixed at the path where it started running (however, since it's another terminal, that's how it should be).

[olimorris]

No, there's not currently a way to do this. I can't imagine this is a problem that users are going to be facing too often where a buffer is open and its file path changes and this would be the same regardless of whether we use relative paths or not.

[gitsang]

In fact, this scenario might be quite often.

For example, if I ask CodeCompanion to modify src/code while in the project root directory /path/to/project, the LLM might modify ./src/code. Then, if I open src/code in my editor to review the changes, and I have vim.opt.autochdir = true, my working directory will change to /path/to/project/src. If I then ask CodeCompanion to modify the file again, it will still look for ./src/code, but because of autochdir now it refers to /path/to/project/src/src/code. The model might realize the path discrepancy, but it still results in an unnecessary request.

Modifying the code with the LLM while simultaneously reviewing the results is a common workflow, It’s just that most people probably don't have autochdir enabled.