[FEATURE]: apply plugin / MCP / config changes without restarting the running session

Verification

• I have checked that this feature has not been suggested before. Related existing issues were found and are referenced below; this request complements them with a prioritized, source-grounded implementation path.

Problem

Today, any change to the config file (opencode.json), the plugin array, or MCP server definitions requires a full restart of opencode (and every client built on it, e.g. OpenChamber) before it takes effect. Config is read once at startup, plugins are resolved/imported once, and MCP servers are connected once.

This is a real friction point in daily use:

• Adding or updating an MCP server forces a session restart, losing the working context.
• Updating a plugin (e.g. bun add <pkg>@latest into the plugin cache) has no effect until the next launch.
• Iterating on your own plugin while developing requires restart-looping.

Current behavior (from source)

• packages/opencode/src/config/config.ts — config is loaded once during startup (loadGlobal / loadLocal); nothing watches the files afterwards (there is an experimental OPENCODE_EXPERIMENTAL_FILEWATCHER flag, but it does not reload config).
• packages/opencode/src/plugin/loader.ts — plugins are resolved + dynamically imported once; hooks are registered into the global event system with no unregister/refresh path.
• packages/opencode/src/mcp/index.ts — MCP servers are connected once at startup (tools/defs cached in global state). Notably, disconnect/connect primitives already exist, and ToolListChangedNotification already triggers a tool-def refresh — so per-server reconnect is almost possible today.
• packages/opencode/src/plugin/shared.ts — resolvePluginTarget() runs bun add <pkg>@latest into ~/.cache/opencode/packages/<pkg>@latest; the cache dir is rebuilt automatically on next start, but the running process never sees the new code.

Proposed approaches (any would be welcome, ordered by effort)

1. Config hot-reload + MCP dynamic reconnect (smallest, highest ROI)

   • Watch config files (the experimental filewatcher already exists); on change, reload and diff:
     • model / permission / agent / provider options → swap the global config object, apply immediately;
     • MCP changes → disconnect() the affected servers and connect() them again (primitives already exist).
   • This solves the most common case (MCP + config changes) without touching the plugin system.

2. Plugin isolation (VSCode extension-host model)

   • Run plugins in a separate worker/VM with a hook registry that supports unregister; on update, kill + rebuild the worker. This is the industry-standard answer to hot-loading extensions (VSCode, browser extensions).

3. Per-step runtime recomputation (Codex model)

   • runtime_config_for_step + dirty-marking + lazy refresh (as in openai/codex's session/mcp.rs). Architectural change, but proven.

Acceptance criteria (for approach 1)

• Editing opencode.json (e.g. adding/removing an MCP server) takes effect in the running session after a short debounce, without restart.
• Changing model/permission/agent settings applies without restart.
• Updating an npm plugin in the cache prompts the user that the plugin code will be picked up on next launch (or, with approach 2, reloads live).

Related issues

• #37421 — Hot reload MCP server configuration: covers MCP config hot-reload specifically. Approach 1 of this request is that issue's scope plus config-level hot-reload.
• #34492 — Add unified file watching and hot reload service: covers a unified watch/reload service. This request builds on that direction with a diff-and-apply semantics and per-server reconnect.
• #8751 — Hot-reload agents, skills and commands: covers reloading agents/skills/commands. This request adds the MCP + plugin-cache update angle and a worker-isolation option (approach 2).

If maintainers prefer to consolidate, this issue can serve as the umbrella discussion — the three approaches above are deliberately ordered by effort so a subset can be accepted independently.

Notes

• Codex achieves this by recomputing its MCP runtime every step (mcp_runtime_for_step, refresh_mcp_if_dirty) — a useful reference implementation.
• Happy to help implement approach 1 if maintainers agree on the direction.