Repository navigation
Description
Description
While a web app page is open, an evicted location is booted again within a fraction of a second, so idle eviction never takes effect.
Evicting a location stops its MCP servers, and stopServer (packages/core/src/mcp/index.ts) publishes mcp.resources.changed and mcp.status.changed for that location, after location.shutdown. The client's event handler (packages/client/src/solid/data.ts, case "mcp.status.changed" / "mcp.resources.changed") invalidates and re-fetches that location's MCP servers and resources. It does this for any location, including ones the page isn't showing. That GET /api/mcp/resource?location[directory]=… boots the location again: config, plugins, file watchers and every MCP server. The boot then publishes provider.updated, model.updated, agent.updated, command.updated and so on, which the page re-fetches too.
On my desktop service, every location the server had loaded (17 of them) was evicted and booted again within 5 s every hour, all day. In the proxy's access log, the first request after each eviction is that /api/mcp/resource call from an open Firefox tab. A side effect: re-resolving the location un-archives its project. A project I had archived in the database came back at the next eviction.
Possible fixes: don't publish MCP change events while a location shuts down, or have the client skip mcp.*.changed for a location it has no data for (or that just sent location.shutdown).
Plugins
None needed (reproduced with only a stub stdio MCP server)
OpenCode version
2.1.4 (the handlers in data.ts and stopServer are unchanged on dev as of 3de8f3a)
Steps to reproduce
- Config with any local MCP server and
"experimental": { "location_idle_timeout": "1 minute" }, thenopencode serve. - Boot a location:
GET /api/location?location[directory]=<project>. Subscribe to/api/event. - With no page open: after about a minute the log shows
location services evicted,/api/eventshowslocation.shutdownthenmcp.resources.changedandmcp.status.changedfor the location, and it stays evicted. - Open the web app (
/?auth_token=…) and boot the location again. At each eviction the log showslocation services bootedabout 0.16 s later and the MCP server is launched again. Measured: evicted 20:17:39.985, booted 20:17:40.145; evicted 20:19:40.054, booted 20:19:40.216. - Close the page: the next eviction (20:21:40) sticks.
Screenshot
No response
Operating System
Linux (WSL2 Ubuntu 24.04); web app in Firefox and headless Chrome on Windows
Terminal
N/A (web app)
Activity
opencode-agent commentedon Oct 24, 2026
Thanks for the detailed report. I reproduced this on 2.1.4, and it still happens on the latest
dev(0093fe5).Setup: a stub stdio MCP server,
experimental.location_idle_timeout: "1 minute",opencode serve, and one location booted through/api/location.location.shutdown, thenmcp.resources.changedandmcp.status.changed.location services evicted, the page sendsGET /api/mcp/resource?location[directory]=…. The location and its MCP server are then booted again. On 2.1.4: evicted 20:33:01.344, booted 20:33:01.431.dev: same result. Evicted 20:37:00.420, page request at .851, booted 20:37:01.342. In that run the page hadn't loaded that location's catalogs beforehand, so the refetch happens for any location, as you described.The
mcp.status.changed/mcp.resources.changedhandlers inpackages/client/src/solid/data.tsstill refetch with no check that the location is loaded, and the client doesn't handlelocation.shutdown. I didn't check the un-archiving side effect. The script below reproduces the eviction and re-boot.Reproduction script (repro.sh)
Run it:
bash repro.sh