Summary
A long-lived agent-bundle dev server whose project sources changed substantially after startup (edits + external agent-bundle build runs from another process) reached a state where the MCP playground looked healthy but could not execute tool calls:
- Open MCP session: OK (
Session ready, negotiated connection shown, initialize/tools list frames in the trace).
List tools / List resources: OK — full catalog rendered.- Call tool (
conductor_status, no args): the operation appeared under Active operations (callTool · mcp-page-2) but no tools/call client frame was ever written to the Raw protocol trace, Invocation history stayed at "No completed invocations yet", and nothing timed out even though the session showed Active session timeout: 30000 ms (waited > 60s).
- The Active operations list also kept the earlier
listTools · mcp-page-1 entry as active even though the trace showed listTools … phase: succeeded.
Killing that dev server and starting a fresh one on the same project made the identical flow work immediately (tool call completed in ~0.5s, app preview opened).
Context
- agent-bundle preview
560124af, Node 22.23.1, Linux.
- The stale server had been started by another agent session before several commits landed in the project (hooks/operations/config changes); its selected build/epoch id predated the current artifact.
- Consumer project: an
agent-bundle plugin with one stdio MCP server (conventional src/mcp/<id>.ts factory) and an MCP App.
Expected
Either the rebuild pipeline republishes an epoch the playground can call, or the bound session surfaces an error/timeout ("epoch superseded / restart session") — anything but an untraced, indefinitely-pending callTool with a stale Active-operations feed.
I don't have an exact minimal repro; filing as an observed-behavior report with the full symptom set in case the epoch-pinning path makes the cause obvious.
Summary
A long-lived
agent-bundle devserver whose project sources changed substantially after startup (edits + externalagent-bundle buildruns from another process) reached a state where the MCP playground looked healthy but could not execute tool calls:Session ready, negotiated connection shown, initialize/tools list frames in the trace).List tools/List resources: OK — full catalog rendered.conductor_status, no args): the operation appeared under Active operations (callTool · mcp-page-2) but notools/callclient frame was ever written to the Raw protocol trace, Invocation history stayed at "No completed invocations yet", and nothing timed out even though the session showedActive session timeout: 30000 ms(waited > 60s).listTools · mcp-page-1entry as active even though the trace showedlistTools … phase: succeeded.Killing that dev server and starting a fresh one on the same project made the identical flow work immediately (tool call completed in ~0.5s, app preview opened).
Context
560124af, Node 22.23.1, Linux.agent-bundleplugin with one stdio MCP server (conventionalsrc/mcp/<id>.tsfactory) and an MCP App.Expected
Either the rebuild pipeline republishes an epoch the playground can call, or the bound session surfaces an error/timeout ("epoch superseded / restart session") — anything but an untraced, indefinitely-pending callTool with a stale Active-operations feed.
I don't have an exact minimal repro; filing as an observed-behavior report with the full symptom set in case the epoch-pinning path makes the cause obvious.