No diff shown when accepting changes from Claude Code

[BorekStastny]

Pre-submission checklist

• I have read the documentation
• I have updated the plugin and all dependencies to the latest versions
• I have searched for existing issues and discussions
• My issue is not a minor or cosmetic quirk (e.g., formatting, spacing, or other non-functional details)

Neovim version (nvim -v)

NVIM v0.11.4

Operating system/version

macOS 15.5 (24F74)

Adapter and model

Claude Code ACP

Describe the bug

When asking Claude Code to make changes to #{buffer}, no diff with changes is shown. Changes are written correctly to the buffer, however, I would expect a diff to be shown first.

Steps to reproduce

1. Open neovim with the minimal.lua
2. Open new chat
3. Send a simple prompt: "Make some changes in #{buffer}"

Expected behavior

Diff view is shown when agent asks for a permission to write as depicted here: #2030

Screenshots or recordings (optional)

Screen.Recording.2025-09-09.at.9.49.08.mov

minimal.lua file

---@diagnostic disable: missing-fields

--[[
NOTE: Set the config path to enable the copilot adapter to work.
It will search the following paths for a token:
  - "$CODECOMPANION_TOKEN_PATH/github-copilot/hosts.json"
  - "$CODECOMPANION_TOKEN_PATH/github-copilot/apps.json"
--]]
vim.env["CODECOMPANION_TOKEN_PATH"] = vim.fn.expand("~/.config")

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

-- Your CodeCompanion setup
local plugins = {
	{
		"olimorris/codecompanion.nvim",
		dependencies = {
			{ "nvim-treesitter/nvim-treesitter", build = ":TSUpdate" },
			{ "nvim-lua/plenary.nvim" },
			-- Test with blink.cmp (delete if not required)
			{
				"saghen/blink.cmp",
				lazy = false,
				version = "*",
				opts = {
					keymap = {
						preset = "enter",
						["<S-Tab>"] = { "select_prev", "fallback" },
						["<Tab>"] = { "select_next", "fallback" },
					},
					cmdline = { sources = { "cmdline" } },
					sources = {
						default = { "lsp", "path", "buffer", "codecompanion" },
					},
				},
			},
			-- Test with nvim-cmp
			-- { "hrsh7th/nvim-cmp" },
		},
		opts = {
			--Refer to: https://github.com/olimorris/codecompanion.nvim/blob/main/lua/codecompanion/config.lua
			strategies = {
				--NOTE: Change the adapter as required
				chat = { adapter = "claude_code" },
				inline = { adapter = "claude_code" },
			},
			adapters = {
				acp = {
					opts = {
						show_defaults = false,
					},
					claude_code = function()
						return require("codecompanion.adapters").extend("claude_code", {})
					end,
				},
			},
			opts = {
				log_level = "DEBUG",
			},
		},
	},
}

-- Leaving this comment in to see if the issue author notices ;-)
-- This is so I can tell if they've really tested with their own minimal.lua file

require("lazy.minit").repro({ spec = plugins })

-- Setup Tree-sitter
local ts_status, treesitter = pcall(require, "nvim-treesitter.configs")
if ts_status then
	treesitter.setup({
		ensure_installed = { "lua", "markdown", "markdown_inline", "yaml", "diff" },
		highlight = { enable = true },
	})
end

-- Setup nvim-cmp
-- local cmp_status, cmp = pcall(require, "cmp")
-- if cmp_status then
--   cmp.setup({
--     mapping = cmp.mapping.preset.insert({
--       ["<C-b>"] = cmp.mapping.scroll_docs(-4),
--       ["<C-f>"] = cmp.mapping.scroll_docs(4),
--       ["<C-Space>"] = cmp.mapping.complete(),
--       ["<C-e>"] = cmp.mapping.abort(),
--       ["<CR>"] = cmp.mapping.confirm({ select = true }),
--       -- Accept currently selected item. Set `select` to `false` to only confirm explicitly selected items.
--     }),
--   })
-- end

Log output (optional)

No response

Minimal reproduction confirmation

• Yes, I have tested and provided a minimal.lua file that reproduces the issue

[olimorris]

Thanks — your minimal.lua and reproduction steps look sufficient to reproduce. I’m not closing this issue. A few quick requests to help maintainers debug:

• Please paste the exact chat transcript (the assistant’s response) that asked for permission to write and any patch/diff text it returned. That lets us see whether Claude returned a unified diff, multi-file patch, or inline edits.
• Reproduce with log_level = "DEBUG" (you already set it) and attach the Neovim output (:messages) and any CodeCompanion log file produced after reproducing the problem. This is essential to see the plugin’s decision path.
• Try the same steps using a different adapter (for example copilot) and report whether a diff view appears — this will tell us if it’s adapter-specific.
• Please include the exact prompt and a small sample buffer (or file contents) you used so we can reproduce the exact edits. Also note the UI flow you used (opened chat, sent prompt, accepted write immediately, etc.).

If you provide the transcript + logs + sample file, we can triage further and either fix the adapter handling or the UI flow. (If you’d like, paste the requested items here and I’ll take another pass.)

[BorekStastny]

There is nothing in :messages

When using Anthropic http adapter with tools, diff is shown as expected.

Sample buffer:
Greetings, everyone!
Here's an updated message.

Prompt:
Make some changes in #{buffer}

[olimorris]

I don't believe this is a CodeCompanion issue. We implement the agent client protocol so it's up to Claude Code to output the diff as per the spec at https://agentclientprotocol.com/protocol/tool-calls#diffs

Feel free to share the RPC output from the logs to show me otherwise.

[BorekStastny]

I have gone through the log and it does indeed seem to contain message with content "type": "diff". Line 67 of the attached log. It seems to be in the correct format. Maybe it is a message sequence issue?

codecompanion.log

[olimorris]

For the clarity of anyone else reading this issue, referencing your logfile, you're seeing two updates.

1. The diff:

{
    "jsonrpc": "2.0",
    "method": "session/update",
    "params": {
        "sessionId": "01992e15-e1e7-7262-af71-23f93ea6452f",
        "update": {
            "toolCallId": "toolu_01EyeLpzh5t2h6qnfGkyMbTo",
            "sessionUpdate": "tool_call",
            "rawInput": {
                "abs_path": "/Users/bstastny/projects/test1/hello.txt",
                "old_string": "This file has been updated with new content.",
                "new_string": "This file has been updated with new content.\nThanks for using our project!"
            },
            "status": "pending",
            "title": "Edit `/Users/bstastny/projects/test1/hello.txt`",
            "kind": "edit",
            "content": [
                {
                    "type": "diff",
                    "path": "/Users/bstastny/projects/test1/hello.txt",
                    "oldText": "This file has been updated with new content.",
                    "newText": "This file has been updated with new content.\nThanks for using our project!"
                }
            ],
            "locations": [
                {
                    "path": "/Users/bstastny/projects/test1/hello.txt"
                }
            ]
        }
    }
}

2. Followed by the permission call:

{
    "jsonrpc": "2.0",
    "id": 0,
    "method": "session/request_permission",
    "params": {
        "options": [
            {
                "kind": "allow_always",
                "name": "Always Allow",
                "optionId": "allow_always"
            },
            {
                "kind": "allow_once",
                "name": "Allow",
                "optionId": "allow"
            },
            {
                "kind": "reject_once",
                "name": "Reject",
                "optionId": "reject"
            }
        ],
        "sessionId": "01992e15-e1e7-7262-af71-23f93ea6452f",
        "toolCall": {
            "toolCallId": "toolu_01EyeLpzh5t2h6qnfGkyMbTo",
            "rawInput": {
                "abs_path": "/Users/bstastny/projects/test1/hello.txt",
                "old_string": "This file has been updated with new content.",
                "new_string": "This file has been updated with new content.\nThanks for using our project!"
            }
        }
    }
}

Thus far, I've built the diff around the following payload (which Gemini CLI follows):

{
    "jsonrpc": "2.0",
    "id": 0,
    "method": "session/request_permission",
    "params": {
        "sessionId": "370030f3-a287-4054-b2a7-010b4bb084e8",
        "options": [
            {
                "optionId": "proceed_always",
                "name": "Allow All Edits",
                "kind": "allow_always"
            },
            {
                "optionId": "proceed_once",
                "name": "Allow",
                "kind": "allow_once"
            },
            {
                "optionId": "cancel",
                "name": "Reject",
                "kind": "reject_once"
            }
        ],
        "toolCall": {
            "toolCallId": "write_file-1754861800410",
            "status": "pending",
            "title": "Writing to test.txt",
            "content": [
                {
                    "type": "diff",
                    "path": "test.txt",
                    "oldText": "This is some old text",
                    "newText": "This is some new text"
                }
            ],
            "locations": [],
            "kind": "edit"
        }
    }
}

So in summary, Claude prefers to make an edit and then ask the user to approve / reject it rather than just show the edit to the user.

This is a potentially tricky workflow to have to account for. I'll have a think if and how we could account for this.

Might be worth raising this upstream too

[BorekStastny]

I see the issue, thank you. Feel free to change this bug report to a discussion, however, I must say that the current handling of Claude ACP messages makes it very hard to use as a coding agent. The main issue is that the user doesn't see the changes they are asked to accept.

I have looked at the current integration of Claude in the Zed and Intellij editors. The common action both editors take is to display the diff directly in the chat window. This is probably as a result of processing the "session/update", which contains the diff. Following that, the user is asked for permission and see the changes again as a diff in the edited file.

Looking through the CodeCompanion repo, I see a couple of admittedly not so great options of handling the Claude message sequence.

1. Process the first message and display the diff in the chat, then process the second message asking for permission "as is"
2. Use the data in the second message for the diff, toolCall.rawInput has all the diff data needed
3. Introduce some sort of state to correlate between the diff message and the permission message

Option 1 doesn't actually show the diff in the edited buffer, Option 2 does not seem as per the ACP specification (although it might be what the Intellij plugin actutally does), Option 3 has obvious downsides of a stateful processing.

[olimorris]

I'll flag this with the Zed team tomorrow. It might be they're facing restrictions in how they've implemented the adapter and they may require native support with Claude Code.

[Keyruu]

Man, I was so hyped to finally use CodeCompanion again, but this just killed it for me again. Awesome stuff you are doing, but without a diff the ACP functionality is pretty useless imo.

[olimorris]

Regardless of what the Zed team come back with, we'll get this working in the plugin in the coming weeks.

[olimorris]

Confirmation from the Zed team that Claude Code's current behaviour is working as expected. Gemini CLI is the abnormal one.

I'm going to implement my current memory PR over the weekend and then turn my attention to Claude Code.

[olimorris]

Hi All

This has been patched in v17.22.1 alongside another issue where Claude Code would output the whole of a file's content after an fs/read_text_file call.

I'll also be merging another patch tomorrow for a better diff UI.

[dirodriguezm]

I've been seeing this exact behavior with OpenCode as well 😞

[olimorris]

This has been fixed for a while. If there's no diff, it's because OpenCode isn't sending one