fix(tmux): add config options to prevent OSC response leak into Neovim buffer

[e-cal]

Add config options for creating a split in tmux:

provider = {
  tmux = {
    focus = false,              -- Focus the opencode pane when created (default: false)
    disable_passthrough = true, -- Disable allow-passthrough on the pane (default: true)
  },
}

Details

When tmux has allow-passthrough on configured, launching opencode writes =31337;OK to the buffer (an iTerm2 OSC 1337 response).

Caused by opencode TUI querying terminal capabilities on startup with nvim pane still in focus.

#143 also aims to address this issue via auto-focus, so opencode eats the OSC response as its meant to.

Some users may prefer keeping the launch in the background, others may require allow-passthrough in the opencode pane. So, I propose making your choice of workaround a config option.

I make disable_passthrough = true by default though since this is the less invasive workaround and most users won't notice the difference anyway.

[Copilot]

Pull request overview

This PR aims to fix an issue where launching opencode with tmux's allow-passthrough on configuration causes OSC 1337 responses (=31337;OK) to leak into the Neovim buffer. The fix proposes adding configuration options to allow users to choose between two workarounds: disabling passthrough on the opencode pane or focusing the pane on creation.

Changes:

• Adds logic to disable allow-passthrough on the opencode tmux pane after creation
• Updates the split-window command to handle missing self.opts.options safely with or ""

Comments suppressed due to low confidence (4)

lua/opencode/provider/tmux.lua:81

• The PR description mentions config options focus and disable_passthrough that should control the behavior, but the current implementation unconditionally disables passthrough without checking any configuration. According to the description, users should be able to configure this behavior with provider.tmux.disable_passthrough (default: true) and provider.tmux.focus (default: false). The implementation should respect these config options rather than always disabling passthrough.

---Start `opencode` in pane.
function Tmux:start()

lua/opencode/provider/tmux.lua:81

• This check for non-empty pane_id is insufficient. The vim.fn.system call can return error messages or other text besides just the pane ID. Consider checking the exit code of the tmux command and verifying the pane_id format matches tmux's pane ID pattern (e.g., %number). Currently, any non-empty output will pass this check, potentially causing the subsequent tmux set-option command to fail silently or target the wrong pane.

---Start `opencode` in pane.
function Tmux:start()

lua/opencode/provider/tmux.lua:78

• The PR description indicates that users should be able to choose whether to focus the new pane via a focus config option (default: false). However, the code always uses the -d flag which prevents focus. To support the focus option, the code should conditionally include the -d flag only when focus is false (or when the option is not set, given the default is false). When focus is true, the -d flag should be omitted so the new pane receives focus immediately, allowing opencode to consume the OSC response.

end

lua/opencode/provider/tmux.lua:78

• The result from vim.fn.system should be trimmed and stored before being used. Currently, self.pane_id may contain trailing newlines or whitespace from the tmux command output, which is only trimmed in the subsequent command. This could cause issues if self.pane_id is used elsewhere. Consider assigning the trimmed result immediately: self.pane_id = vim.trim(vim.fn.system(...))

  end
end

---

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

[disrupted]

is the opencode TUI still able to receive the response and figure out the terminal capabilities if we disable tmux passthrough?

[e-cal]

Sort of, allow-passthrough just makes tmux pass on escape sequences to the terminal instead of handling them itself. Everything still displays and works correctly, you just give up some features.

The main limitations of having it off in the opencode pane are:

• can't display images
• can't use special (terminal specific; non-system) clipboards
• may have issues setting window properties like the title

And this is all bound to only the opencode pane. Most users wouldn't notice anything different, and those that do (e.g. make use of terminal clipboards) can turn it off and use the other workaround.

[e-cal]

This is why I think it should be a config option, not forced.

[disrupted]

This is why I think it should be a config option, not forced.

agreed! I've closed my initial PR since yours supersedes it