Plugin config changes are not picked up by registered tools without plugin re-activation

[MarlBurroW]

Summary

When a user changes a plugin's config via the UI (Settings > Plugins > Configure), the registered tools of that plugin keep using the OLD config until the plugin is explicitly deactivated/reactivated (or the service is restarted). Newly saved config values silently do not apply to subsequent tool invocations.

Reproduction

1. Install and activate the claude-code plugin.
2. Leave binaryPath empty in the config, save.
3. Trigger plugin_claude-code_claude_code_run from a Kin. The session will fail with "Claude Code native binary not found".
4. Open the plugin config in the UI, set binaryPath to a valid value (e.g. /home/user/kinbot/node_modules/@anthropic-ai/claude-agent-sdk-linux-x64/claude), save.
5. Without restarting/reactivating, trigger plugin_claude-code_claude_code_run again.
6. Expected: the new binaryPath is used, the session starts.
7. Actual: the old (empty) binaryPath is still used, the error repeats.

Workaround today: toggle the plugin off and on from the UI, or restart kinbot.service. Both work because they force a fresh activate() call.

Root cause hypothesis

Plugin tools are registered once during activate(ctx) and the ctx.config is captured by closure in the tool's create() factory or in the inner execute(). When configure_plugin (or the equivalent UI call) updates the stored config, nothing invalidates the captured reference.

Relevant code paths to audit:

• src/server/services/plugins.ts: search for activate(ctx) and how ctx.config is provided. If it's a plain object snapshot (which it appears to be from past audits, see commit 94baaa85 for claude-code plugin), config mutations after activation are invisible to running tools.
• src/server/routes/plugins.ts (or wherever configure_plugin lands): check whether saving config triggers a deactivate -> activate cycle on the affected plugin. If not, the config write is silent.
• Pattern reference: plugins/claude-code/index.ts captures config: ClaudeCodeConfig from the outer activate(ctx) and uses it inside launchSession via closure. Same pattern likely in twilio-sms, teamspeak, home-automation.

Proposed fix (one of)

Option A (simplest, recommended): when configure_plugin saves a config change, automatically deactivate then reactivate the plugin. UX feedback: small toast "Plugin reloaded with new config". This is what users do manually today, just automated. Acceptable behavior for the few-second blip.

Option B (more refined): give plugins a live config reference instead of a snapshot. The ctx.config becomes a getter that reads from the store on every access. Plugin tools naturally see fresh values. More invasive (touches PluginContext shape) but no reload required.

Option C: emit a plugin:config-changed event that the plugin can subscribe to, allowing it to refresh its own state. Most flexible but adds API surface and plugin author burden.

Option A is the lowest-cost fix for users. Option B is the cleanest long-term answer. Either is acceptable; pick based on how invasive the audit shows the closure capture to be across the 6 existing plugins.

Acceptance criteria

• Saving a plugin config from the UI (or via configure_plugin tool) causes subsequent tool invocations to use the new values, without any user action.
• All 6 existing plugins (claude-code, twilio-sms, teamspeak, home-automation, example-weather, example-provider) continue to work correctly.
• Brief documentation note in docs/plugins.md explaining the behavior (especially relevant for plugin authors using Option B or C).

Observed environment

• KinBot v0.41.0
• systemd user service (user: marlburrow)
• claude-code plugin v0.1.0
• Reported by MarlBurroW directly during a live test on May 12, 2026.

[MarlBurroW]

Starting automated implementation...

Quick audit notes for the dev sub-task:

• PluginManager.setConfig() in src/server/services/plugins.ts (around line 1180) already calls deactivatePlugin → activatePlugin when the plugin is enabled, so the closure-capture should in theory be refreshed. The bug suggests this cycle is either not firing on one of the code paths or deactivatePlugin is not fully tearing down the tool registrations (stale closures survive).
• The relevant entry points are PUT /api/plugins/:name/config (src/server/routes/plugins.ts:248) and the configure_plugin tool (src/server/tools/plugin-tools.ts:212) — both go through pluginManager.setConfig().
• Investigate deactivatePlugin() and the tool/hook/provider unregister logic to confirm registrations are cleared before re-activation, then verify with a quick repro using the claude-code plugin path described in the issue.
• Prefer Option A (reactivate on save) since the cycle is already wired in — focus on making it actually work end-to-end. Touch docs/plugins.md with a short note.