Skip to content

tui: plugins disabled in Ctrl+P Plugins dialog are re-enabled on session switch #55506

Closed as duplicate

Description

@ls-pavel-makhov

Summary

Disabling a plugin in the Plugins dialog (Ctrl+P → Plugins → Disable) only deactivates it in memory. It is not saved to cli.json, so plugins come back after a plugin reconciliation, for example when switching to another session. Users see their disabled plugins reappear.

Environment

  • opencode version: 2.0.29
  • OS: Darwin 25.6.0 (macOS, arm64)
  • Terminal: TERM_PROGRAM=herdr, TERM=xterm-256color, COLORTERM=truecolor
  • Shell: /bin/zsh
  • Install/channel: latest (release)

Reproduction

  1. Configure several TUI plugins in ~/.config/opencode/cli.json under plugins.
  2. Open the TUI, press Ctrl+P → Plugins, and disable one or more plugins. They disappear from the UI.
  3. Check ~/.config/opencode/cli.json: it is unchanged (mtime unchanged, no -<id> entries added).
  4. Switch to another session (in my case, other sessions are in different working directories).
  5. The disabled plugins are active again.

Expected Behavior

A plugin disabled from the Plugins dialog stays disabled. The choice should persist, for example as a -<id> entry in cli.json (the format the docs describe for disabling plugins), or the dialog should make clear that the toggle is temporary.

Actual Behavior

The toggle is session-local. Reading the 2.0.29 binary, the dialog's Disable action calls plugins.deactivate(id), which only runs the plugin's cleanups and sets it inactive in memory. The reconciliation routine rebuilds the plugin list from config every time JSON.stringify([serverTuiPlugins, config.plugins]) changes or a watched plugin directory changes. In that rebuild every plugin gets enabled: true unless config has a -id directive. The in-memory active=false is compared against enabled=true and the plugin is reactivated.

The server-side plugin list is requested per location, so switching to a session in a different directory can change it and trigger reconciliation. I confirmed that "plugin reconciliation started/completed" is logged by every running TUI process at once, but I did not verify the exact trigger on session switch.

Activity

  1. opencode-agent commented on Oct 14, 2026

    @opencode-agent
    Contributor

    Thanks for the detailed report and the analysis of the reconcile path, @ls-pavel-makhov!

    I think this is a duplicate of #42417. That issue tracks the same problem: a plugin disabled through /plugins is only deactivated in memory, so the next plugin reconcile from config turns it back on, and the choice isn't saved. In your case the session switch changes the location, which re-fetches the server plugin list and starts that reconcile.

    Possible duplicates and related issues, ordered by likelihood:

    The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.

  2. ls-pavel-makhov commented on Oct 14, 2026

    @ls-pavel-makhov
    Author

    Duplicate of #42417. Added the session-switch trigger there.

  3. opencode-agent commented on Oct 14, 2026

    @opencode-agent
    Contributor

    Thanks for confirming, @ls-pavel-makhov, and for adding the session-switch trigger to #42417. Follow-up on this bug will happen there. The bot will close this issue as a duplicate as planned.

  4. opencode-agent commented on Oct 15, 2026

    @opencode-agent
    Contributor

    Closing this as a duplicate of #42417, as you confirmed. Thanks again for the detailed report and for adding the session-switch trigger there. Please follow #42417 for updates on saving plugin enable/disable choices from the Plugins dialog.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions