[FEATURE]: Will 2.0 config hot-reload expose an HTTP/SDK trigger for headless serve? #43698

Activity

1. github-actions

   assigned

   neriousy

   on Aug 20, 2026
2. jayati-naik commented on Aug 20, 2026

   

   jayati-naik

   on Aug 20, 2026

   Author

   More actions

   Follow-up: we're pinned to the v1.18.x line and can't move to v2 until it has a stable release, so I'd specifically like to request this fix be patched into the current v1.18.x line rather than v2-only.

   Proposed as minimal and opt-in, so it's a no-op unless explicitly enabled — no behavior change for existing users:

   A POST {instance}/config/reload on the experimental instance API that reuses the existing InstanceStore.reload machinery to rebuild Config + Provider (model/provider catalog) state from disk, gated behind an env flag (defaulting off) — similar in spirit to the earlier OPENCODE_CONFIG_HOT_RELOAD prototype in #4285.
   I'm happy to submit this as a small, self-contained PR against the v1 line (endpoint + handler + test) if you'd accept it. Could you confirm whether a v1.18.x backport is acceptable, or whether runtime reload is strictly v2-only?
3. neohiro commented on Aug 29, 2026

   

   neohiro

   on Aug 29, 2026

   More actions

   File-Based Trigger + Idle Sessions-Only Reload

   This is exactly the right ask. Adding use-case detail to push it forward:

   Trigger Surface

   Beyond /reload slash command and HTTP/SDK trigger for headless serve, a simple opencode reload-config CLI subcommand is the lowest-friction trigger. Symmetric with the existing opencode serve, opencode run, opencode auth. No new mental model.

   Safety Conditions (built in)

   Reload should be gated on sessions-idle, with a clear error otherwise:

   $ opencode reload-config
     Reloading config...
     ✗ Aborted: 3 sessions are active.
       Use --force to reload anyway (active sessions will keep their state).
   

   --force reload applies config to all sessions; without it, only idle sessions adopt the new config.

   Related Adjacent Issues

   These would all be resolved or substantially helped by a unified reload:

   • skills: project .agents created after startup is not discovered until config reload #42478 "skills: project .agents created after startup is not discovered until config reload" — needs reload
   • [Bug] Plugin config hook not re-invoked after /connect — agents disappear #30955 "Plugin config hook not re-invoked after /connect — agents disappear" — needs reload
   • feat(tui): diff plugin generations on reconcile instead of full teardown #39777 "feat(tui): diff plugin generations on reconcile instead of full teardown" — also needs reload trigger
   • GET /event?directory= stream is killed by PATCH /config (instance dispose), starving directory-scoped subscribers #36495 "GET /event?directory= stream killed by PATCH /config" — adjacent: PATCH should trigger reload, not dispose
   • [FEATURE]: slash command for reload #6719 "slash command for reload" — the user-facing surface for the same thing

   Plugin Angle

   A plugin could subscribe to config.reloaded events and re-initialize their state — letting plugins be dynamically configurable without restart, which unlocks live-tuning workflows.

   One Final Note

   The current approach of "edit JSON, restart OpenCode, lose session context" is a significant friction point for power users who iterate on config. A 50ms reload gated on idle sessions would make OpenCode feel significantly more alive.

   ---

   🦙 Creative Monkey at FrenzyPenguin Media — open-source security hardening & privacy tools
4. neohiro commented on Aug 29, 2026

   

   neohiro

   on Aug 29, 2026

   More actions

   Hey @thdxr @adamdotdevin @fwang @Brendonovich — fully behind this. Adding: a simple opencode reload-config CLI subcommand (symmetric with opencode serve, opencode run) plus a --force flag for active-session reload. Also flagging config.reloaded as a plugin event to enable dynamic plugin re-initialization. Resolves #42478, #30955, #39777 as a side effect. 🦙 Creative Monkey at FrenzyPenguin Media
5. jayati-naik commented on Sep 1, 2026

   

   jayati-naik

   on Sep 1, 2026

   Author

   More actions

   Thanks @neohiro , agree with all of this, and it lines up with the existing InstanceStore.reload machinery, so the surface (reload-config CLI + HTTP/SDK trigger + config.reloaded plugin event, idle-gated with --force) is small and additive.

   @thdxr @adamdotdevin @fwang @Brendonovich , the only thing blocking a PR is one decision: is a v1.18.x backport acceptable, or is runtime reload strictly v2-only? We're pinned to v1.18.x and can't move to v2 until it's stable, so a v2-only answer means we can't consume this. If v1 is OK, I'll open a small self-contained PR (endpoint + handler + test) behind an off-by-default flag. Just need a yes/no on the v1 line.
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for checking before opening a PR, @jayati-naik! You're asking whether v2 has a programmatic way to make a long-running headless opencode serve re-read its config and rebuild the provider/model catalog without restarting.

   It already does, since v2.1.0:

   • HTTP: POST /api/location/reload. It shuts down and rebuilds every loaded location, so config, providers and models are read fresh. Pending permissions and forms are cancelled, running sessions carry on with the rebuilt services at their next step, and a location.shutdown event is emitted so clients can recover. It responds once all the rebuilds have finished.
   • SDK: client.location.reload() in @opencode/client.
   • CLI: opencode reload, which calls that endpoint on the running server.

   The internals mentioned in the issue (InstanceStore.reload, markInstanceForReload, initGit in handlers/project.ts) are from the 1.x codebase and don't exist in v2, so a new config/reload endpoint would duplicate this one. If you're on 1.x, upgrading to v2 (@opencode/cli) gives you this endpoint.

   Related issues you may want to follow for a multi-session backend:

   • opencode reload interrupts in-flight turns and leaves them permanently stuck in running — session unusable until a full restart #59726: opencode reload can interrupt turns that are in progress and leave them stuck
   • Prompt POSTed to session HTTP endpoint during config-reload window is persisted but excluded from assembled context; assistant re-emits previous reply byte-identically #51584: a prompt sent while a reload is running can be left out of the session context
   • V2: Reconcile provider catalogs with /models endpoints #40524: reconciling v2 provider catalogs with an upstream /models endpoint (your gateway case)
   • server: GitHub Copilot model sync and opencode.json changes require manual service restart to take effect #53413: provider/model changes that needed a service restart
   • plugins: hot reload makes the server unavailable #42898 / fix(server): serve last settled models from /api/model while plugins reload #57011: keeping /api/model available while a reload is in progress

   If this endpoint doesn't cover your use case (for example, you need to reload a single location, or refresh only the catalog without rebuilding everything), please reply with the details and maintainers will consider it.
7. neriousy commented on Nov 13, 2026

   

   neriousy

   on Nov 13, 2026

   Member

   More actions

   Closing as completed. V2 can reload config without a restart in three ways: the POST /api/location/reload endpoint, client.location.reload() in the SDK, and the opencode reload command (see the CLI docs). Each one rebuilds the loaded locations, so config and providers are read again. Config files are also watched, and a change triggers a reload automatically. Runtime reload exists in V2 only, and V1 is frozen, so there won't be a 1.18 backport. If you need to reload just one location, please open a new issue.
8. neriousy

   closed this as completedon Nov 13, 2026