bug: When write is called on a file that does not exist yet, opencode.nvim is not able to pull up the diff in nvim.

[r0ckHopper]

Prerequisites

• I searched the docs
• I searched existing issues

:checkhealth opencode output

==============================================================================
opencode: 1 ⚠️

opencode.nvim ~

• OS: Linux 6.19.11-200.fc43.x86_64 (x86_64)
• nvim version: 0.12.1+v0.12.1.
• opencode.nvim git commit hash: 615634114c93335a4e7f76d943b4ba787ab364dd.
• vim.g.opencode_opts: {
  events = {
  permissions = {
  floating = true
  }
  },
  lsp = {
  enabled = true
  }
  }

opencode.nvim [binaries] ~

• ✅ OK opencode available with version 1.17.11.
• ✅ OK curl available.
• ✅ OK pgrep available.
• ✅ OK lsof available.

opencode.nvim [snacks] ~

• ✅ OK snacks.input enabled: ask() enhanced.
• ⚠️ WARNING snacks.picker disabled: select() enhanced.

Describe the bug

When you ask opencode to make an edit on a file that does not exist you get the following error
Cannot resolve OpenCode edit target file: /location/file.txt

Steps To Reproduce

1. Ask opencode to make an edit to a nonexistent file using write tool
2. get error in nvim messages

Expected Behavior

Should pull up a diff against an empty file which user can accept or reject from within nvim using da/dr

[r0ckHopper]

Actually, this was intended design based on the following in lua/opencode/events/permissions/edits.lua

    if vim.fn.filereadable(filepath) ~= 1 then
      vim.notify("Cannot resolve OpenCode edit target file: " .. filepath, vim.log.levels.ERROR, { title = "opencode" })
      return
    end

Maybe this was implemented when opencode did not handle file checking for its edit tool which it does now.
I would propose removing this cause when the file does not exist nvim compares to an empty buffer, which would be intended use.

I can put up a PR after more indepth testing.

[nickjvandyke]

Ah good catch! Thanks for digging a bit too.

Hmm, that check was added because OpenCode apparently sometimes sends a malformed filepath (i.e. neither absolute nor stable-y relative) #287

I wonder if some check could handle both cases?

Maybe this was implemented when opencode did not handle file checking for its edit tool which it does now.

If you mean that the edited filepath is reliable now and we can remove the check entirely, that'd be great!

[r0ckHopper]

If you mean that the edited filepath is reliable now and we can remove the check entirely, that'd be great!

It is speculation on my part, I don't know for sure. But I didn't see this double path issue in my testing (where I just deleted that filereadable check).

I found a similar issue on opencode's side which has been closed and the comments say it was fixed somewhere else.
anomalyco/opencode#4967

But there is no guarantee that without concrete repro steps.
@zawedcvg Do you have repro steps for your original issue so we can confirm if this has been fixed in new opencode releases?

[zawedcvg]

I don't think this issue is fixed in the latest ones, as I was testing on 1.17.x. If you ever faced an malformed issue with opencode.nvim, it was because of the different paths. I don't have a way to exactly reproduce the issue with opencode tbh. However, one thing you can try is to revert back to a commit of this plugin before #287 was merged. Its been a while so I don't remember exactly what it was, but basically the idea was to go to a repository, and test a couple of things:
toggle opencode from the base of the repo and test changes in a file couple of subdirectories down.
toggle opencode from some subdirectory and try out the same thing. One of these should lead you to have the malformed issue. One more thing you can do is just add logging to the path that opencode.nvim receives before the if statements. You will see that it is not always uniform.

Though yeah, my fix isn't perfect. I ran into the same issue you did. But I think you can parse the header of the diff to see if it is creating a new file or now. I could possibly take a look at doing that in a week or so when I have the time, but it should be doable.

Also, slight followup to what I mentioned it in my previous PR, the patch received by the plugin isn't exactly correct, because opencode sends a processed diff for pretty print, so you will probably run into some issues when using the edit buffer feature. I raised an issue in opencode anomalyco/opencode#31625, and someone made a PR for it anomalyco/opencode#33476, but it hasn't gotten attention from the maintainers yet, probably because of the large amount of PRs.

[r0ckHopper]

toggle opencode from the base of the repo and test changes in a file couple of subdirectories down.
toggle opencode from some subdirectory and try out the same thing.

I commented out the code but wasn't able to repro, does the following look correct?

test1

• open nvim and opencode --port at ~/
• prompt opencode to edit ~/.config/nvim/lua/exp/init.lua
• opencode pulls up a diff

test2

• open opencode --port at ~/
• open nvim at ~/.config/nvim
• prompt opencode to edit ~/.config/nvim/lua/exp/init.lua
• opencode pulls up a diff

For the repro steps are you opening opencode from within nvim? or have a separate instance via opencode --port outside of nvim?

demo of repro steps

test1

recording_2026-07-07_23-28-07.mp4

test2

recording_2026-07-07_23-47-10.mp4

[zawedcvg]

sflr, but I wasn't using port, just starting it from nvim, using the toggle command. Have you never faced the E816 issue when running with port? in that case, maybe it has something to the way toggle assigns paths to open code? idk

[nickjvandyke]

I don't think the start method would matter - OpenCode will have the same CWD, and I would hope only that affects the diff filepath.

I can confirm I got E816 before the fix, but also don't know how to reliably reproduce it 😞

[nickjvandyke]

Re trimmed diff issues: I wonder if we could "un-trim" it ourselves? https://github.com/anomalyco/opencode/blob/c69abee0c73253aebae65e87e4e1b9bfa8c38021/packages/opencode/src/tool/edit.ts#L646 i.e. just add back the +++ and --- header with the edit event's filepath. It seems unimportant for :diffpatch anyway - the given patch must be for the current buffer. It might not even actually parse the files in the header.

[zawedcvg]

I am not completely sure. I need to take a look. But from what I can tell from first glance, it lowkey looks like a destructive operation, don't know if its possible to reconstruct it. will look further into it

[nickjvandyke]

Regarding E816, anyone feel free to use the plugin for a while prior to that fix or with the fix commented out, and report back if E816 still appears. Seems to be the case for @r0ckHopper at least, but I'd want a bit more confirmation. If it's mysteriously gone, then I'm down to remove the fix to resolve this issue.

[nickjvandyke]

...everything working smoothly without the workaround? Shall I remove it?

[zawedcvg]

I ran into this issue on my work nvim config, which isn't updated yet. It has opencode version 1.18.16

[r0ckHopper]

Still no issues for me without the workaround. I wonder if it is OS dependent. I'm on linux + wayland.