You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MCP prompts/list failure wipes the cached prompt list and announces it as empty #50918
refreshPrompts turns a failed prompts/list into an empty list and then commits it: Effect.orElseSucceed(() => []) at packages/core/src/mcp/index.ts:307, and the Effect.map below it assigns entry.prompts from that empty result before publishing PromptsChanged (:305-312). refreshTools directly above (:298-303) has no such swallow, so a failed tools refresh leaves the registered tools alone. The two listings behave differently on the same failure.
So one transient error on a server that is still connected wipes its prompts, and the event that follows tells every reader the list is now legitimately empty — packages/core/src/plugin/command.ts:18-24 reacts to PromptsChanged by re-reading mcp.prompts() and calling ctx.command.reload(). The server's slash commands disappear and nothing indicates why: servers() still reports status: "connected".
Plugins
None.
OpenCode version
v2 at 681ea07a9.
Steps to reproduce
Using the resourceServer fixture in packages/core/test/mcp.test.ts, with prompts capability advertising listChanged and a responder that answers prompts/list with a JSON-RPC error once armed:
Connect; the initial listing succeeds and service.prompts() contains greet.
The server sends prompts/list_changed; the client re-lists and the server answers with the error.
service.prompts() is now [], while service.servers() still reports { status: "connected" }.
Expected: the failed refresh keeps the prompts it already had, as refreshTools does. The regression test in the PR fails on 681ea07a9 with prompts were [] and passes with the one-line change.
Thanks for the detailed report. I can confirm this on the latest dev (fa1260d).
To reproduce it, I changed the resourceServer test fixture so its prompts capability advertises listChanged: true and prompts/list can be made to fail on demand. Then I connected through Mcp.Service and waited until service.prompts() returned ["greet"]. Next I made prompts/list fail and sent notifications/prompts/list_changed:
service.prompts() became [].
service.servers() still reported { status: "connected" }.
When I removed Effect.orElseSucceed(() => []) from refreshPrompts, the failed refresh kept greet, which matches how refreshTools behaves. The script below reproduces it against a source checkout.
Activity
opencodejr commentedon Oct 28, 2026
Thanks for the detailed report. I can confirm this on the latest
dev(fa1260d).To reproduce it, I changed the
resourceServertest fixture so its prompts capability advertiseslistChanged: trueandprompts/listcan be made to fail on demand. Then I connected throughMcp.Serviceand waited untilservice.prompts()returned["greet"]. Next I madeprompts/listfail and sentnotifications/prompts/list_changed:service.prompts()became[].service.servers()still reported{ status: "connected" }.When I removed
Effect.orElseSucceed(() => [])fromrefreshPrompts, the failed refresh keptgreet, which matches howrefreshToolsbehaves. The script below reproduces it against a source checkout.Reproduction script (repro.sh)
Run it:
bash repro.sh