how to set up the plugin with tmux?

[bpingris]

with a recent update the provider option has been removed, i was using it to use tmux

			vim.g.opencode_opts = {
				provider = {
					enabled = "tmux",
				},
			}

but now i can't find what is the option to have the same behaviour?
I tried to look at the source of the plugin but it's not clear for me what i need to change.
thanks!

[bpingris]

wtf

[nickjvandyke]

It's not officially supported anymore because it wasn't practical to maintain. But you can still achieve the same functionality yourself! Here is the tmux provider code just prior to removal: https://github.com/nickjvandyke/opencode.nvim/blob/6d00f3094af83748f94224647f62a215bca6a920/lua/opencode/provider/tmux.lua

start at least should be pretty copy-pastable into your config, using https://github.com/nickjvandyke/opencode.nvim#customization as a reference for the new option 🙂

[msgongora]

Hey @nickjvandyke it is sad to see that tmux won't be supported anymore, that was the main reason I started to use your plugin. I personally prefer to use tech and tools for what they are specialized for and unfortunately, Neovim isn't specialized in terminals, but tmux does. It was good until it lasted, thank you tho.

[nickjvandyke]

@msgongora maybe you are misunderstanding the plugin? It connects to opencode running anywhere, even in a tmux pane. The only difference is that now you have to launch/manage that pane yourself. An extremely minor inconvenience.

It's just not sustainable for me to officially support so many workflows that frankly have little relation to or impact on the plugin's core offering. Managing external programs would make much more sense as a separate plugin, and I encourage anyone to yoink the removed code for that 🙂

[msgongora]

I understand the architecture of opencode, it's just that when I tried the default you were shipping months ago, it didn't feel natural for me and didn't fully support my workflows. I'll give it another try to see if it fits me in the current state, but I understand your reasons, as this is an opinionated implementation. Before the agentic era, I was using GitHub Copilot, which used a client/server architecture, and it felt natural at the time.
While it may not fit my workflows moving forward, I'm appreciative of your efforts.

[nickjvandyke]

In my opinion that minor convenience (which can be re-added per this discussion) does not make or break this plugin, but you are free to customize your environment how you like 🙂 I also encourage you to consider that it frees up more time to improve the plugin's core functionality 😀

[e-cal]

@msgongora I made and will maintain https://github.com/e-cal/opencode-tmux.nvim for tmux support (since I also heavily use this).

I like the idea of more of a telescope.nvim style repo, with this as the core functionality and a community maintained set of extensions for all the specific functionalities we want.

[fayimora]

Here is my current starting point. I am still resolving any minor issues I encounter while using it.\

config = function()
  local opencode_pane_id = nil
  local opencode_visible = false

  local function pane_exists()
    if not opencode_pane_id then
      return false
    end
    local check = vim.fn.system("tmux has-session -t " .. opencode_pane_id .. " 2>/dev/null; echo $?")
    if vim.trim(check) == "0" then
      return true
    end
    opencode_pane_id = nil
    opencode_visible = false
    return false
  end

  local function start()
    if pane_exists() and opencode_visible then
      return
    end

    if pane_exists() then
      -- Bring the hidden pane back into the current window
      vim.fn.system("tmux join-pane -h -l 35% -s " .. opencode_pane_id)
    else
      -- Create a new pane
      local result = vim.fn.system "tmux split-window -h -p 35 -P -F '#{pane_id}' 'opencode --port'"
      opencode_pane_id = vim.trim(result)
    end
    opencode_visible = true
  end

  local function stop()
    if not pane_exists() then
      return
    end
    -- Send C-c for clean shutdown, then kill the pane
    vim.fn.system("tmux send-keys -t " .. opencode_pane_id .. " C-c")
    vim.defer_fn(function()
      vim.fn.system("tmux kill-pane -t " .. opencode_pane_id)
      opencode_pane_id = nil
      opencode_visible = false
    end, 500)
  end

  local function toggle()
    if not pane_exists() then
      start()
    elseif opencode_visible then
      -- Hide the pane into a background window (keeps process alive)
      vim.fn.system("tmux break-pane -d -s " .. opencode_pane_id)
      opencode_visible = false
    else
      -- Bring it back
      vim.fn.system("tmux join-pane -h -l 35% -s " .. opencode_pane_id)
      opencode_visible = true
    end
  end

  vim.g.opencode_opts = {
    server = {
      start = start,
      stop = stop,
      toggle = toggle,
    },
  }

  -- Required for \`opts.events.reload\`.
  vim.o.autoread = true
end

[nickjvandyke]

See the recent https://github.com/e-cal/opencode-tmux.nvim, courtesy of @e-cal ! 🙏

[fayimora]

Nice thanks, i'll check it out

[Anaritus]

Would you mind adding this link in documentation? Almost uninstalled this plugin because of seemingly dropped tmux support. Took me way longer to find this thread since there is not mention in README, latest code or even issues (atleast I couldn't easily find among closed ones)

Also a personal opinion: I think provider option is not as minor as you might think, atleast for me its half the plugin, where the other one is sending data between instances of nvim and opencode (new diff feature is fun though). Adding more to it, currently the opencode-tmux.nvim is broken because of changes to this one, which is precisely why those types of separations are bad. Right now the option below is working, but who knows what will happen next?

Please consider returning some type of prebuilt servers, even without support. Just make them extendable so that when it breaks people can update it. Even this is better.

[nickjvandyke]

Thanks for your thoughts @Anaritus - I hear you!

Providers solve an entirely different - and complicated - problem. Launching opencode via such a solution is just one application of it. Please see my message on the commit that removed providers for my detailed reasoning: 82332cf

currently the opencode-tmux.nvim is broken because of changes to this one, which is precisely why those types of separations are bad. Right now the option below is working, but who knows what will happen next?

Good ole integration hell! But we should solve this with a more stable and flexible config interface. Which I plan to do, once I conceive the right design. I would hate to do it wrong and then have to make another large breaking change later. There are so many workflows to consider.

I like your suggestion to add a link in the documentation, and will do so once it stabilizes 🙂

[allisnulll]

Here is how I do it:

vim.g.opencode_opts = {
    server = {
        start = function()
            vim.system({"tmux", "split-window", "-h", "-l", "40%", "opencode", "--agent", "plan", "--port"}):wait()
            vim.system({"tmux", "select-pane", "-l"})
        end,
        stop = function()
            local pane_id, pane_pid = vim.fn.system("tmux list-panes -F '#{pane_id} #{pane_pid} #{pane_current_command}' -t . | grep opencode"):match("(%S+)%s+(%S+)")

            vim.system({"kill", "-9", pane_pid})
            vim.system({"tmux", "kill-pane", "-t", pane_id})
        end,
        toggle = function()
            local output = vim.fn.system("tmux list-panes -F '#{pane_current_command}' -t . | grep opencode")
            if output == "" then
                vim.g.opencode_opts.server.start()
            else
                vim.g.opencode_opts.server.stop()
            end
        end,
    }
}

vim.api.nvim_create_autocmd("VimLeave", {
    callback = vim.g.opencode_opts.server.stop,
})