OpenCode.nvim Feature Requests

👋 Hello opencode.nvim Team!

First off, thank you for creating such an incredible Neovim integration! The opencode.nvim plugin has become an essential part of my daily development workflow, and I deeply appreciate all the hard work you've put into making OpenCode seamlessly accessible from Neovim.

These feature requests come from a place of genuine enthusiasm and a desire to contribute back to the project. I've been using opencode.nvim extensively and have built workarounds for some common pain points I've encountered while integrating it with my Neovim setup. Rather than keeping these solutions to myself, I wanted to share them in the hope they might benefit the wider community.

I've tried to be as thorough as possible with each request - including real code examples, use cases, and working implementations - but I'm completely open to alternative approaches. These are meant to be conversation starters, not prescriptions. I know you have a much deeper understanding of the plugin architecture and OpenCode integration, so please feel free to adapt, modify, or even reject these ideas as you see fit.

If any of these features align with your roadmap, I'd be happy to contribute PRs or help in any way I can. And if they don't fit the project's direction, that's totally fine too - I'm just grateful for the amazing plugin you've already built!

This directory contains feature request proposals for opencode.nvim, prioritized by impact and based on real-world usage patterns from this configuration.

Overview

These feature requests address common pain points when integrating OpenCode with custom Neovim setups. Each request includes:

• Clear problem statement from user perspective
• Current workarounds with code examples
• Proposed solutions with API designs
• Implementation considerations for maintainers

Feature Requests

Current Workarounds

This configuration implements all requested features as workarounds:

plugins/ai/
├── opencode_ui_patches.lua           # → Feature #1 (70 lines of monkey-patching)
├── opencode_integration.lua          # → Feature #2 (165 lines managing LSP/features)
├── opencode_force_stop.lua           # → Feature #3 (112 lines of manual cleanup)
├── opencode_diagnostics/             # → Feature #4 (561 lines across 4 modules)
│   ├── log_parser.lua
│   ├── health_ui.lua
│   ├── monitors.lua
│   └── init.lua
├── opencode_favorites.lua            # → Feature #5 (51 lines custom picker)
└── opencode_build_mode.lua           # → Feature #6 (48 lines quick helper)

Total workaround code: ~1,000 lines that could be replaced by clean APIs.

Why These Features?

Built from Real Usage

These requests aren't theoretical - they solve actual problems encountered during daily use:

• Monkey-patching breaks on updates → Need official UI customization API
• LSP popups interrupt AI generation → Need focus mode
• OpenCode occasionally gets stuck → Need emergency stop
• Hard to debug when things break → Need diagnostics system
• Switching models is tedious → Need favorites
• Repetitive prompts waste time → Need templates

Benefit Multiple User Groups

All Users:

• Emergency stop API (reliability)
• Diagnostics system (self-service debugging)

Custom Status Bar Users (lualine, heirline, etc.):

• UI integration API (eliminate monkey-patching)

Power Users:

• Focus mode (better UX)
• Provider favorites (faster workflows)
• Quick actions (efficiency)

Submitting to Upstream

When ready to submit:

1. Choose priority order - Start with high-impact requests
2. One issue per feature - Keep discussions focused
3. Reference this config - Link to implementation as proof-of-concept
4. Be flexible - Maintainers may prefer different API designs
5. Offer to help - Propose contributing PRs if interested

Reference Implementation

Full working implementation available at:

• OpenCode Configuration - Complete plugin configuration
• Main README - Detailed module descriptions and documentation

Discussion

Each feature request is independent and can be discussed/implemented separately. Maintainers are welcome to:

• Propose alternative API designs
• Merge related features
• Split features into smaller chunks
• Prioritize differently based on upstream roadmap

Updates

• 2025-12-08: Initial feature requests created based on configuration refactoring
• Status updates will be tracked here as issues are submitted/resolved

Questions or feedback? Open an issue in this repository or discuss in the upstream opencode.nvim project.