Repository navigation
[FEATURE]: apply plugin / MCP / config changes without restarting the running session #39987
Closed as not planned
Description
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>@latestinto 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 experimentalOPENCODE_EXPERIMENTAL_FILEWATCHERflag, 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/connectprimitives already exist, andToolListChangedNotificationalready triggers a tool-def refresh — so per-server reconnect is almost possible today.packages/opencode/src/plugin/shared.ts—resolvePluginTarget()runsbun add <pkg>@latestinto~/.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)
-
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 andconnect()them again (primitives already exist).
- This solves the most common case (MCP + config changes) without touching the plugin system.
- Watch config files (the experimental filewatcher already exists); on change, reload and diff:
-
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).
-
Per-step runtime recomputation (Codex model)
runtime_config_for_step+ dirty-marking + lazy refresh (as inopenai/codex'ssession/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
- Hot reload MCP server configuration #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.
- [FEATURE]: Add unified file watching and hot reload service #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.
- [FEATURE]: Hot-reload agents, skills and commands. #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
Codexachieves 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.
Reacted by Scott Williams and Mauricio Scheffer
Activity
github-actions commentedon Aug 1, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
[FEATURE]:per the feature request template.Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
[-]Feature request: apply plugin / MCP / config changes without restarting the running session[/-][+][FEATURE]: apply plugin / MCP / config changes without restarting the running session[/+]github-actions commentedon Aug 1, 2026
Thanks for updating the issue! It now meets our contributing guidelines. We appreciate the detailed write-up and the references to related issues.
AllanSantos-DV commentedon Aug 23, 2026
Hi! We independently opened #44389 (explicit opt-in plugin reload) before finding this one — closing it in favor of this broader request.
Offering our plugin-specific findings to fold in here, from reading the current
devsource:packages/opencode/src/plugin/loader.tsnotes Bun caches failed dynamic imports for the process lifetime, so even fixing a broken plugin requires a full restart.packages/opencode/src/plugin/index.ts). An atomic swap gives clean semantics: sessions started after reload observe the new version; already-running sessions keep their current hooks and toolset (documented, intentional).~/.cache/opencode/packages/<pkg>/), so an explicit trigger (opencode plugin reload [spec], plusPOST /plugin/reloadfor UIs) complements the watching approach discussed in [FEATURE]: Add unified file watching and hot reload service #34492 rather than competing with it.Happy to take the plugin slice of this behind a design review if useful.
liudongyan13701205717-source commentedon Oct 3, 2026
Same friction here — I run OpenCode Desktop and constantly hit this: adding/removing an MCP server, enabling a plugin, swapping a model, or editing AGENTS.md/agent config all force a full session restart, losing the working context. It's a daily friction point, especially when iterating on local MCP configs and plugins.
Approach 1 (config hot-reload + MCP dynamic reconnect) would cover most of my use cases. Happy to test once it lands.
AllanSantos-DV commentedon Oct 4, 2026
Thanks @liudongyan13701205717-source — same here, it's a daily friction point for me too: iterating on local MCP configs and plugins means losing the session every time. Really hoping this gets a maintainer go-ahead soon. The plugin slice I outlined above is ready to implement once the design is approved, and I'll ping you for testing as soon as there's a build to try.
liudongyan13701205717-source commentedon Oct 4, 2026
Appreciate you picking this up. The
plugin/loader.tsnote about Bun caching failed dynamic imports for the process lifetime is the detail that makes this a recovery problem, not just an iteration-speed one — fixing a broken plugin without a full restart is the higher-value half.trollkarlen commentedon Oct 19, 2026
+1 with a concrete use case for approach 1's "changing model/agent settings applies without restart" criterion.
Scenario: per-agent model routing via a plugin config file (
~/.config/opencode/oh-my-opencode-slim.jsonc), where each specialist agent (orchestrator, oracle, explorer, fixer, …) carries its ownmodel/variant.Repro (v2.0.30, Linux, tmux):
modelin the plugin config (e.g. orchestrator:opencode/big-pickle→opencode/nemotron-3-ultra-free)Why the current workaround is heavier than a restart:
opencode service restartreloads the plugin config server-side, but a session that's already open keeps the agent roster/model wiring assembled at session start — and/modelonly swaps the primary session model, not plugin-defined specialists. So the practical path is restart plus opening a new session, losing the working context this issue is about.A diff-and-apply on agent model settings (acceptance criterion 2) would ideally also cover plugin-contributed agent definitions — or expose a
/reloadthat re-resolves agent→model bindings for new delegations within an existing session.AllanSantos-DV commentedon Oct 24, 2026
Re-checked on V2
dev(c272a63cb4): reload without restart is implemented..opencode/pluginsor in the configpluginslist, and editing helper modules a plugin imports, reactivates plugins automatically (file watcher, 100 ms debounce). If the new version fails to load, the previous one keeps running.opencode reload,/reloadin the TUI,POST /api/location/reload.packages/core/test/plugin/supervisor-reload.test.ts(add/remove discovered plugin, add/remove plugin via config).Suggest closing this as resolved by V2, unless someone needs a plugin-only (not whole-location) manual reload.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up, @severin-ye!
The code paths you cite (
packages/opencode/src/config/config.ts,plugin/loader.ts,mcp/index.ts,plugin/shared.ts) are from OpenCode v1 (versions 0.x/1.x, theopencode-ainpm package). v1 now only gets fixes for critical bugs, so new features like this are unlikely to be added there.The good news is that v2 (
@opencode/cli, versions 2.x) already does most of what you're asking for:/reloadcommand to reload the configuration by hand.Related issues, all done in v2:
If you can, please try v2. If you see this problem on v2 too (for example, a config, MCP or plugin change that isn't picked up), or if you think there's a critical v1 problem here, reply with your
opencode --versionand the steps, and we'll take another look.opencodejr commentedon Oct 29, 2026
Closing this as not planned. The request is based on OpenCode v1, which only gets critical fixes, and we haven't heard back.
v2 (
@opencode/cli) already reloads config files, MCP servers and plugins while it's running, and has a/reloadcommand (see #37421, #34492 and #8751). If a config, MCP or plugin change isn't picked up on v2, please open a new issue with youropencode --versionand the steps. Thanks again for the detailed write-up!