Skip to content

[Bug] Plugin config hook not re-invoked after /connect — agents disappear #30955

Closed as not planned

Description

@jayedisonGit

Description

Bug Description

After using the /connect command to switch models/providers, OpenCode does not re-invoke plugin config hooks. This causes plugins that register custom agents (e.g., oh-my-openagent) to lose all their agents from the TUI agent selector — only the default build/plan agents remain.

Steps to Reproduce

  1. Install a plugin that registers custom agents via the config hook (e.g., oh-my-openagent v4.7.5)
  2. Start opencode — custom agents appear correctly in the selector
  3. Use /connect to switch to a different model
  4. Open the agent selector — all plugin-registered agents are gone
  5. Agents do not return until opencode is fully restarted

Expected Behavior

After /connect switches the model, OpenCode should re-invoke all plugin config hooks so plugins can re-register their agents, tools, and other configurations against the new provider/model context.

Actual Behavior

The config hook is not called after /connect. Plugin-registered agents disappear from the selector and do not return until opencode is fully restarted.

Technical Analysis

I investigated the bundled oh-my-openagent v4.7.5 code:

  • The plugin registers its config handler via config: managers.configHandler in the plugin interface
  • On startup, OpenCode calls this hook and agents are registered successfully
  • After /connect, the provider/model is updated but the plugin config hook is never called again
  • The plugin attempted a fix (fix(agent-config): refresh agent registry on config apply code-yeongyu/oh-my-openagent#4294) that adds clearRegisteredAgentNames() before re-registration, but since the hook is never called after /connect, this code is dead code in this scenario
  • The plugin has no other hook/event mechanism to detect model switches (there is no provider.change or similar event hook available)

Environment

  • OpenCode: v1.16.0 (also reproduced on v1.15.13)
  • oh-my-openagent: v4.7.5
  • OS: Windows Server 2022 (x64)

Related

Suggested Fix

Re-invoke plugin config hooks after /connect completes the model/provider switch. Alternatively, provide a new hook/event (e.g., provider.change) that plugins can subscribe to for responding to model switches.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Activity

  1. VitaliyVV commented on Aug 4, 2026

    @VitaliyVV

    I hit the same symptom (plugin agents disappear, only build/explore/general/plan remain) but with a different trigger and a different root cause than described here. Posting my evidence.

    Trigger: NOT /connect. The opencode instance was silently recreated ~21s after TUI start — logs show "creating instance" (04:25:51) → "disposing instance" (04:26:12, single dispose, NOT disposeAll) → "creating instance" again (04:26:12). The long-lived session ended up in the SECOND instance. I suspect /connect may hit the same instance-recreation path rather than a separate bug.

    Key finding: the plugin config hook WAS invoked in both instances — 12 agents applied at 04:25:53 AND at 04:26:12. So "config hook not re-invoked" is NOT the cause here; the hook runs fine. Re-invoking hooks after /connect would not fix this case.

    Root-cause hypothesis: opencode's agent registry is materialized lazily and cached forever (InstanceState/ScopedCache with Duration.infinity, agent/agent.ts). In the second instance the agent list was queried BEFORE the plugin hook finished applying, so the registry froze with the stale config (only the 4 default agents). From then on every plugin-agent request fails with "Agent not found" until a full restart.

    Evidence that fresh processes work: a fresh opencode serve + GET /agent sees all 16 agents; the long-lived instance sees only 4. Touching opencode.jsonc does NOT reproduce the loss (verified with a poll loop) — so this is a startup race, not a config-reload path.

    Suggested fix direction: do not cache the agent registry forever — re-materialize it after plugin config hooks apply, or invalidate the agent cache when an instance is recreated.

    Env: opencode 1.18.12, [email protected], Windows, TUI.


    (RU / для русскоязычного читателя)
    Столкнулся с тем же симптомом (агенты плагина пропадают, остаются только build/explore/general/plan), но триггер и причина у меня другие.

    Триггер: НЕ /connect. Инстанс opencode молча пересоздался ~через 21 секунду после старта TUI (в логах: creating instance → disposing instance → creating instance). Сессия оказалась во втором инстансе. Возможно, /connect попадает в тот же путь пересоздания инстанса — это стоит проверить.

    Ключевое: config-хук плагина вызывался В ОБОИХ инстансах (12 агентов применены и в 04:25:53, и в 04:26:12). Значит гипотеза «хук не перевызывается» неверна — хук работает. Перевызов хука после /connect эту проблему НЕ решит.

    Рабочая гипотеза: реестр агентов opencode материализуется лениво и кэшируется навсегда (InstanceState/ScopedCache, Duration.infinity). Во втором инстансе список агентов запросили ДО применения плагин-хука — реестр застыл со старым конфигом (только 4 дефолтных агента). Дальше любой запрос агента плагина падает с "Agent not found" до полного перезапуска.

    Свежие процессы видят все 16 агентов (проверено: serve + GET /agent), долгоживущий — только 4. Touch opencode.jsonc баг НЕ воспроизводит — это гонка при старте, а не config-reload.

    Направление фикса: не кэшировать реестр агентов навсегда — перематериализовывать после применения config-хуков, либо инвалидировать кэш агентов при пересоздании инстанса.

    Окружение: opencode 1.18.12, [email protected], Windows, TUI.

  2. github-actions commented on Oct 4, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions