clio-agent v0.9.1.1
Emergency hotfix for a capability-loss bug reported by a real user on 0.9.1.
The bug
On a slow or contended filesystem (an NFS home directory, several sessions
cold-starting at once), some of a blueprint's MCP servers could fail to come
up in their 10-second setup window or lose the launcher-cache lock race — and
that loss was permanent for the run. The affected expert simply ran
without its declared tools (a geospatial expert with no geo tools), and the
only place the cause was visible was a cache listing.
What changed
- Sessions start instantly. Activating a blueprint no longer spawns any
MCP servers up front. Recently-seen servers are visible immediately from
the listing cache. - Servers mount on demand. The first time an expert or a tool call
actually needs a server, it is mounted right then. Concurrent needs for the
same server share a single mount instead of racing duplicate spawns. - Slow is not dead. Waiting is driven by liveness, not clocks: a cold
install that is genuinely progressing is waited out; a lock held by a live
process is respected; a lock left behind by a dead process is broken
automatically. The old 10-second setup cliff and fail-fast lock are gone. - Failures are never remembered as permanent. A mount that failed is
re-attempted the next time it's needed. - Errors name the server. If a tool genuinely cannot come up, the error
says which server failed to mount and why.
Also fixed along the way: the dispatch-time server spawn bypassed the
launcher-cache lock entirely (the same uv-cache race the discovery path was
already protected against), and a lock-release bug that could leave the OS
lock orphaned when acquire and release ran on different threads.
For users who applied workarounds
CLIO_MCP_CONNECT_MODE=legacy, CLIO_MCP_SETUP_TIMEOUT_S=120, and
CLIO_MCP_LAUNCHER_CACHE_LOCK_TIMEOUT_S=60 are no longer needed. Defaults
now handle slow and contended environments; those knobs remain available as
optional tuning.