bug: opencode working directory doesn't sync with Neovim's actual CWD

[horaoen]

Did you check docs and existing issues?

• I have read all the plugin docs
• I have searched the existing issues
• I have searched the existing opencode issues

Operating system/version

Macos

:checkhealth opencode output

opencode.nvim ~ - ✅ OK nvim version: 0.11.5. - ✅ OK opencode.nvim git commit hash: dfca5bb214d78a600781d50da350238b3e6e2621. - ✅ OK vim.g.opencode_opts: {} opencode.nvim [binaries] ~ - ✅ OK opencode available with version 1.0.202. - ✅ OK curl available. - ✅ OK pgrep available: it will be used to auto-find opencode if vim.g.opencode_opts.port is not set. - ✅ OK lsof available: it will be used to auto-find opencode if vim.g.opencode_opts.port is not set. opencode.nvim [snacks] ~ - ✅ OK snacks.input is enabled: ask() will be enhanced. - ✅ OK blink.cmp is available: opts.ask.blink_cmp_sources will be registered in ask(). - ✅ OK snacks.picker is enabled: select() will be enhanced. opencode.nvim [providers] ~ - ✅ OK Configured opencode provider: snacks. - ✅ OK The snacks provider is available. - ⚠️ WARNING The kitty provider is not available — KITTY_LISTEN_ON environment variable is not set. - ADVICE: - Enable remote control in kitty. - ⚠️ WARNING The wezterm provider is not available — wezterm executable not found in $PATH. - ADVICE: - Install wezterm and ensure it's in your $PATH. - ⚠️ WARNING The tmux provider is not available — Not running inside a tmux session. - ADVICE: - Launch Neovim inside a tmux session. - ✅ OK The terminal provider is available.

Describe the bug

When opencode is launched, it uses the working directory from the moment Neovim starts (where the nvim command was executed), rather than tracking Neovim's actual current working directory. This causes a mismatch when:

1. Using nvim <folder> to open a different directory
2. Navigating to a project via a dashboard plugin (like alpha-nvim, dashboard-nvim, etc.)
3. Changing directories within Neovim using :cd, :tcd, or :lcd

Steps To Reproduce

Steps to Reproduce

Scenario 1: Using dashboard

1. Run nvim from ~/ (home directory)
2. Use a dashboard plugin to open a project at ~/projects/my-app
3. Trigger opencode (e.g., :lua require("opencode").toggle())
4. Expected: opencode opens in ~/projects/my-app
5. Actual: opencode opens in ~/

Scenario 2: Using nvim <folder>

1. From ~/, run nvim ~/projects/my-app
2. Trigger opencode
3. Expected: opencode opens in ~/projects/my-app
4. Actual: opencode may open in ~/ (depends on timing)

Scenario 3: Changing directory after opencode starts

1. Start Neovim in ~/project-a
2. Trigger opencode (it correctly opens in ~/project-a)
3. Use :cd ~/project-b to change Neovim's working directory
4. Try to interact with opencode
5. Expected: opencode should work in ~/project-b or at least detect the mismatch
6. Actual: opencode continues working in ~/project-a

Expected Behavior

expected as 'Reproduce' expected

[NickvanDyke]

imo 2 is okay because nvim's cwd is actually ~/ in that case (for me). The other's aren't huge concerns, but it'd be nice if it stayed in sync! Maybe we can use the DirChanged autocmd for this? Hoping that opencode exposes an API endpoint to change its cwd 🤞

Maybe only for embedded opencodes? Seems confusing to cd external ones.

[horaoen]

imo 2 is okay because nvim's cwd is actually ~/ in that case (for me). The other's aren't huge concerns, but it'd be nice if it stayed in sync! Maybe we can use the DirChanged autocmd for this? Hoping that opencode exposes an API endpoint to change its cwd 🤞

Maybe only for embedded opencodes? Seems confusing to cd external ones.

Thanks for the response! I've actually implemented a solution and submitted a PR that addresses scenarios 1 and 2.

My approach adds a get_project_root() function that intelligently detects the correct working directory when opencode starts, with the following priority:

1. nvim directory argument (e.g., nvim ~/projects/foo)
2. Git root
3. Current buffer directory
4. LSP workspace root
5. vim.fn.getcwd() as fallback

This is called in each provider's toggle()/start() method to set the correct cwd.

Regarding DirChanged autocmd — I agree it would be great for scenario 3 (runtime :cd sync), but it requires opencode CLI to expose an API endpoint for changing its working directory dynamically. As you mentioned, that doesn't exist yet.

I think both approaches are complementary:

• get_project_root() → ensures correct initial directory at startup ✅ (implementable now)
• DirChanged → syncs directory changes at runtime (needs opencode API support)

[FlippingBinary]

FWIW, the snacks provider can take a cwd and manage a different terminal for each one. I tried a little hacky injection to override the start() and toggle() methods with the project cwd, but that didn't work correctly only because opencode.nvim still used the wrong directory to find the opencode instance that it opened. But, my current workaround is to use an autoexec that basically just sets neovim's current directory to the project root by running vim.cmd.cd(LazyVim.root()) every time a buffer is entered. Now it works almost as I'd expect it to. Without closing neovim, I can switch between buffers in different projects and always toggle open the right opencode instance. So if it was up to me, I would just ask that the cwd be configurable with a function that gets run every time start() or toggle() is run. I think that would be easier to maintain as well because then selecting a project root would be clearly out of scope for this plugin.

[NickvanDyke]

The project root solution seems overkill to me. I consider 1 and 2 negligible because the plugin still finds the correct opencode instance, and opencode still resolves injected file references. CWD is plenty and keeps things simple, both in code and for users. (btw snacks.dashboard does seem to change my nvim CWD when I select a project).

3 is the biggest concern because it just stops working. I can't imagine it affects people often, but if a relatively simple solution arises, I'm not opposed!

Or maybe we zoom out here. When we find opencode processes, but none match nvim's CWD, we could prompt the user to select an instance rather than fail? Or expose some configuration related to finding opencode, per above.

[horaoen]

The project root solution seems overkill to me. I consider 1 and 2 negligible because the plugin still finds the correct opencode instance, and opencode still resolves injected file references. CWD is plenty and keeps things simple, both in code and for users. (btw snacks.dashboard does seem to change my nvim CWD when I select a project).项目根目录的解决方案对我来说似乎过于复杂。我认为 1 和 2 可以忽略不计，因为插件仍然能找到正确的 opencode 实例，并且 opencode 仍然能解析注入的文件引用。当前的工作目录已经足够，并且能保持代码和用户使用的简洁性。（顺便说， snacks.dashboard 在选中项目时似乎确实会改变我的 nvim 工作目录）。

3 is the biggest concern because it just stops working. I can't imagine it affects people often, but if a relatively simple solution arises, I'm not opposed!3 是最主要的问题，因为它会导致功能失效。我无法想象这种情况会经常影响用户，但如果出现一个相对简单的解决方案，我并不反对！

Or maybe we zoom out here. When we find opencode processes, but none match nvim's CWD, we could prompt the user to select an instance rather than fail? Or expose some configuration related to finding opencode, per above.或者我们换个角度考虑。当我们找到 opencode 进程，但没有匹配 nvim 的工作目录时，我们可以提示用户选择一个实例而不是失败？或者像上面提到的那样，暴露一些与寻找 opencode 相关的配置？

Perhaps a configuration option could be added to allow users to decide whether switching CWDs changes the OpenCode session. I don't think pausing the previous CWD's OpenCode session is a problem, as this session data is traceable. The solution I can think of right now is to close the session when using the toggle action if the CWD is switched, and create a new OpenCode instance corresponding to the current CWD when the toggle is used again. For some reasons, I don't have the time to help with this issue right now, but I still think it's worth considering. If I switch projects within NeoVim but the OpenCode cannot switch CWDs, I have to exit and reopen NeoVim, which definitely impacts the user experience. I would be happy if this issue could be resolved. By the way, regarding this issue PR, I've tested the Snack part and it works fine, but I'm unsure about other providers.

[NickvanDyke]

If I switch projects within NeoVim but the OpenCode cannot switch CWDs, I have to exit and reopen NeoVim, which definitely impacts the user experience

I definitely agree, and think this is the main issue here. To my understanding, the "project root" solution does not address it?

I wonder if on the DirChanged autocmd we could stop + start the configured provider when it's already running. We'd have to implement Provider.is_running, but I've wanted that for other reasons anyway. Or at least return from Provider.stop whether anything was actually stopped.

Maybe I'll ask in the opencode Discord the LoE for them to add a change cwd API endpoint. That's the ideal solution here, on our end. Importantly, it'd also fix this issue for external opencode instances. Although that may be more surprising to users than embedded instances. 🤔

[FlippingBinary]

The most straight-forward solution would be to use a separate opencode instance for each "project root" and let the user choose how get the path of the project root. That would only require changes in this plugin because the current assumption is that there's only one opencode instance.

I'm currently testing this approach in my fork. It seems to work well so far. Opencode actions work with the correct opencode instance even when more than one is open at a time, and the opencode cwd always matches the project root that I set with a new project_root option. Each of the methods also have an optional cwd parameter for overriding the project_root.

If you want, I can submit it as a pull request.

[horaoen]

If I switch projects within NeoVim but the OpenCode cannot switch CWDs, I have to exit and reopen NeoVim, which definitely impacts the user experience

I definitely agree, and think this is the main issue here. To my understanding, the "project root" solution does not address it?

I wonder if on the DirChanged autocmd we could stop + start the configured provider when it's already running. We'd have to implement Provider.is_running, but I've wanted that for other reasons anyway. Or at least return from Provider.stop whether anything was actually stopped.

Maybe I'll ask in the opencode Discord the LoE for them to add a change cwd API endpoint. That's the ideal solution here, on our end. Importantly, it'd also fix this issue for external opencode instances. Although that may be more surprising to users than embedded instances. 🤔

I agree with this plan. Ideally, OpenCode would provide support. Is there any discussion about this issue on Discord?

[FlippingBinary]

Hey @horaoen and @NickvanDyke! 👋

Just wanted to follow up on my earlier comment. I've been using a solution in my fork that addresses scenarios 1 and 2 (and partially scenario 3) by taking a different approach than the "project root detection" PR.

How it works:

Instead of trying to detect the correct project root automatically, my fork adds a project_root config option that can be a string or a function. This function gets called every time toggle(), start(), or stop() is invoked, so it always uses the current project root (not the one from when Neovim started). This can be overridden when calling the function by supplying a cwd as a parameter.

Each unique project_root gets its own opencode instance, managed separately. So when you switch projects in Neovim (via dashboard, :cd, or opening files from a different project), toggling opencode will open the correct instance for that project. The plugin tracks all the instances internally keyed by their cwd.

Configuration example:

vim.g.opencode_opts = {
  project_root = function()
    return LazyVim.root()  -- or any project detection you prefer
  end,
}

What this addresses:

• ✅ Scenario 1 (dashboard): If your dashboard changes Neovim's cwd or you use a root detection function like LazyVim.root(), toggling opencode will use the correct project.
• ✅ Scenario 2 (nvim <folder>): Works correctly since the cwd/root is resolved at toggle time.
• ⚠️ Scenario 3 (runtime :cd): This works if you supply a function for project_root that tracks the cwd. However, this doesn't change an existing opencode session's cwd (which would require opencode CLI support as you discussed).

Important distinction:

There are really three related but different features at play here:

1. Synchronizing the opencode cwd with the Neovim cwd (what my fork solves)
2. Changing an existing opencode server's cwd
3. Changing an existing opencode session's cwd

My fork handles the first one by managing multiple opencode instances as needed. It's the same pattern used by snacks terminal instead of trying to force a running shell to change its cwd. For the other two, we'd indeed need an API endpoint from opencode itself, as @NickvanDyke mentioned. But the first two are functionally equivalent, and the third might cause cross-session contamination that users would want to avoid.

I'd love for you both to try it out and see if it fits your workflows! If it works well enough, I'm happy to submit a PR. The changes touch config.lua, provider/init.lua, the main opencode.lua module, and the individual providers to pass through the cwd properly.