BREAKING - v19.0.0

[olimorris]

Description

You can try this out by using the develop branch.

This PR will be for v19.0.0 which promises some exciting new features alongside breaking changes. Planned upgrade guide can be found in the Cloudflare comment below.

• A new diff alongside the removal of support for the other diff providers and removal of the super diff (New diff #2600)
• Breaking: Removal of the list_code_usages tool (remove list-code-usages tool #2693)
• Markdown prompt library items can now be in nested dirs (feat(prompts): work with nested dirs #2694)
• MCP support (feat: add MCP client #2549)
• MCP servers are automatically added to ACP adapters (feat(adapters): use mcp server config with acp adapters #2766)
• Customizable prefixes for slash_commands, tools and variables (feat: customizable slash_command, tool and variable prefixes #2710)
• Prompt library items can contain tools and MCP servers (Prompt library can contain tools and MCP servers #2725)
• Breaking: Variables are now editor context (Rename variables to editor context #2719)
• Breaking: Refactor tools API (refactor tools API #2740)
• Fix header navigation in the chat (fix(ui): move between h2 role headers #2751)
• Command tool factory (feat(tools): add cmd_runner factory and rename cmd_runner to run_command #2754)
• cmd_runner tool has been renamed run_command (feat(tools): add cmd_runner factory and rename cmd_runner to run_command #2754)
• Can conditionally enable prompt library items (feat(prompt_library): can enable/disable prompts #2759)
• Can leverage on_before_submit callback (feat(chat): add on_before_submit callback #2760)
• Can automatically add and remove MCP tools from the chat buffer (feat(chat): auto add mcp tools #2764)
• Refactor chat system prompt (refactor(chat): default system prompt and AGENTS.md #2765)

AI Usage

See individual PRs

Screenshots

See individual PRs

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

[cloudflare-workers-and-pages]

Deploying codecompanion with    Cloudflare Pages

Latest commit:	6433926
Status:	✅  Deploy successful!
Preview URL:	https://05c92063.codecompanion.pages.dev
Branch Preview URL:	https://develop.codecompanion.pages.dev

View logs

[bassamsdata]

Hello, I’ve been using the develop branch for a couple of days, and it’s been great. However, I’ve noticed that sometimes the visual text ext_marks keymaps for inline interaction remain in the buffer. I haven’t been able to reproduce this issue consistently, but if you ask LLM to change the same area of the buffer multiple times, the g2 and g3 actions sometimes leave the ext_marks on.

I’m not sure if this is the right PR for such comment. Please hide it if it’s not.

[olimorris]

@bassamsdata thanks for flagging this.

I've actually added a test mode to CodeCompanion that you can enable with:

opts = {
  log_level = "DEBUG",
  test_mode = true,
},

And enabled an inline diff with :CodeCompanionDiffInlineTest n where n is between 1 and 6. More than welcome to play around and see if appears regularly.

[bassamsdata]

Oh, very nice mode!

I have reproducible steps:

1. CodeCompanionDiffInlineTest 5
2. Press g2 (or any action)
3. Type :bn to change the buffer
4. Return to the same test buffer with :bp
5. It appears.

Screen.Recording.2026-01-29.at.6.10.22.PM.mp4

edit: just small typo

[bassamsdata]

I followed up on the namespace lifecycle and found that, for some reason, the namespace clear may not be executed when it's inside the if self.inline scope. This might be related to buffer switching, though I'm not entirely sure.

However, moving line 280 in the clear method in diff/ui.lua outside of that scope fixes the issue on my end. Since the call is already wrapped in pcall, this change shouldn't introduce any side effects.

[olimorris]

@bassamsdata would you be willing to PR this? I'm a few days away from being able to look at this fully.

[bassamsdata]

I was mistaken in my initial debugging; it turns out the autocommands are the issue. PR #2709.

[bassamsdata]

I've been testing this branch regularly while building a fairly large new extension, and I wanted to share a couple of things I've noticed in the latest version.

When using tools like search_file or read_file with tool group @files with Copilot (and sometimes the OpenAI adapter), the stream occasionally ends right after the first tool call. It finishes silently, no errors, and nothing unusual shows up in the debug logs, so I haven't been able to pinpoint the root cause on my end.
Sorry I don't have more concrete details, but I wanted to mention it in case it's something you've also seen or can reproduce.

I just noticed the tools refactor in #2740 👀, this will probably break my heart 😂.
I just finished the extension, and it'll likely require updates on my side and affect the tools I've built. This isn't a complaint at all though, just sharing context.

I'm looking forward to testing the new tools API 🙂

[olimorris]

Thanks for the heads up @bassamsdata. Firstly, I won't merge this until yourself, David (VectorCode) and Ravitemer (MCPHub) have updated your individual plugins and given it the green light. I've added require("codecompanion").version() so you can maintain different tool APIs if required. It's not that bad of a refactor btw, just the parameters that feed into the handlers. You'll be able to more clearly see it tomorrow when I push the final changes.

Regarding the Copilot issue...there have been some issues with it over on https://www.githubstatus.com recently. The fact there's no output or no response seems very odd and makes me think it is likely to be a server issue. Not to say CodeCompanion is always faultless but when it fails it usually does so with a big error message or something explosive 😆.

[cairijun]

Is it possible to provide a prompt to help users check & migrate their config or extension code before a breaking release? (And I think this prompt could be generated from PRs as well.)

[olimorris]

I ask users to pin to a major release throughout the docs and I include an upgrade guide if they do decide to make the move. So they have full control over whether they accept the breaking changes or not.

For most users, a release like this and v18 won't impact them. It's mainly the plugin authors and to that extent, I work with them directly. I very much like the idea of a prompt to help them upgrade though. I will add that in!

[bassamsdata]

there have been some issues with it over on https://www.githubstatus.com/ recently.

That timing was very coincidental for me. Right after I pulled the latest version of develop, I ran into this issue, and it does look like it was caused by GitHub itself. Sorry for the false alarm.

it usually does so with a big error message or something explosive 😆.

That's exactly what I love about CC 😄

[bassamsdata]

After working with this branch for a while, I wanted to share a few observations:

1. Diff hunk calculations – The hunk splitting seems inconsistent. For this change, git diff treats it as a single hunk, and visually it looks like it should result in 2 hunks. However, the current develop behavior splits it into 5 hunks (see attached video).

Is this expected behavior, or could there be an issue in the hunk calculation logic? The relevant code example is included below.

Screen.Recording.2026-02-13.at.6.59.24.PM.mp4

Code example

# Slow bubble-sort implementation
def bubble_sort(arr):
    n = len(arr)
    for i in range(n):
        for j in range(0, n - i - 1):
            if arr[j] > arr[j + 1]:
                # swap
                arr[j], arr[j + 1] = arr[j + 1], arr[j]
    return arr
## ---------------------------------
# Fast built-in sort
def bubble_sort(arr):
    """Use Python's Timsort for O(n log n) performance."""
    return sorted(arr)

2. Tool rejection handling, The rejection flow for tools doesn’t seem to be working properly. In some cases, the tool reacts and stops without providing the rejection reason (except for insert_edit_into_file, which handles rejections internally and doesn’t rely on output.rejected). You can try reproducing this with delete_file and cmd_runner. Could the issue be in the orchestrator?

Happy to dig into any of this further if helpful.

[olimorris]

@bassamsdata probably worth turning this into a separate issue so that I can take a look