fix: lazy load CodeCompanion on commands

[ayamir]

Findings

Issue #1520 reports that saving and quitting with ZZ or :wq can leave a stale Neovim UI in the terminal. The comments narrow this down to an autocmd-related timing issue:

• :w followed by :q works reliably.
• :noautocmd wq avoids the issue.
• Several users reported the problem disappearing when use_chat is disabled.

The current config loads codecompanion.nvim on VeryLazy whenever settings.use_chat is true. That means normal editing sessions load CodeCompanion even if the chat feature is never used.

Further investigation shows that CodeCompanion setup is not a no-op:

• it registers global codecompanion.buffers autocmds and history-extension User autocmds;
• it auto-detects the completion provider during setup;
• that provider detection calls require("blink.cmp"), which can trigger lazy.nvim's module loader;
• in this config, loading blink also activates the blink-copilot/copilot path.

So the old VeryLazy trigger expands the active runtime surface during ordinary edit/save/quit sessions. This matches the issue comments: disabling use_chat avoids the problem even when the user is not actively using chat.

I also checked closed upstream CodeCompanion issues/PRs. I did not find the exact same stale-terminal-UI report, but the related history supports this diagnosis:

• olimorris/codecompanion.nvim#2929 intentionally moved the main completion module load into CodeCompanion.setup() so completion autocmds are registered during setup.
• olimorris/codecompanion.nvim#597 shows that blink provider registration previously depended on chat/filetype timing, and the upstream direction was to register it earlier.
• olimorris/codecompanion.nvim#651 shows the completion provider detection path is sensitive to require(...) side effects (blink.compat made cmp detection ambiguous).
• olimorris/codecompanion.nvim#2286, #2944, and #2949 show that CodeCompanion has had exit-time cleanup issues around spawned ACP processes, including a VimLeavePre fix where the autocmd group had to use clear = false so multiple cleanup callbacks were preserved.

So this does not point to one single broken autocmd in our config. The stronger conclusion is that loading CodeCompanion on VeryLazy opts every normal editing session into CodeCompanion's setup-time completion/autocmd/process surface, even when chat is never used.

Why This Change

This changes CodeCompanion to load only when one of its user-facing commands is executed. That keeps chat functionality available, but avoids installing chat/history autocmds during ordinary edit/save/quit workflows.

This is a conservative fix because it narrows the plugin's active surface instead of changing save/quit behavior globally or disabling the chat feature by default.

Impact

• Normal startup no longer loads CodeCompanion just because use_chat = true.
• ZZ/:wq sessions that do not use chat avoid CodeCompanion's autocmds.
• CodeCompanion still loads on CodeCompanion, CodeCompanionActions, CodeCompanionChat, CodeCompanionCLI, CodeCompanionCmd, CodeCompanionHistory, and CodeCompanionSummaries.
• First use of a chat command may pay the plugin load cost, which is expected for command-based lazy loading.

Fixes #1520

[Copilot]

Pull request overview

Changes the codecompanion.nvim lazy-loading trigger from event = "VeryLazy" to a cmd = {...} list, so the plugin loads only when one of its user-facing commands is invoked. This avoids running CodeCompanion's setup (which registers autocmds and pulls in blink/copilot via completion-provider detection) during ordinary edit/save/quit sessions, addressing the stale-UI report in #1520.

Changes:

• Replace event = "VeryLazy" with a cmd list (CodeCompanion, CodeCompanionActions, CodeCompanionChat, CodeCompanionCLI, CodeCompanionCmd, CodeCompanionHistory, CodeCompanionSummaries) for lazy loading.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.