Repository navigation
Description
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
- Install a plugin that registers custom agents via the
confighook (e.g., oh-my-openagent v4.7.5) - Start opencode — custom agents appear correctly in the selector
- Use
/connectto switch to a different model - Open the agent selector — all plugin-registered agents are gone
- 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.configHandlerin the plugin interface - On startup, OpenCode calls this hook and agents are registered successfully
- After
/connect, the provider/model is updated but the pluginconfighook 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.changeor 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
- oh-my-openagent issue: [Bug] OMO agents disappear from selector after /connect command in OpenCode 1.15.x code-yeongyu/oh-my-openagent#4130
- oh-my-openagent attempted fix (does not help because hook is never called): fix(agent-config): refresh agent registry on config apply code-yeongyu/oh-my-openagent#4294
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
VitaliyVV commentedon Aug 4, 2026
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.
github-actions commentedon Oct 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.