Provisioned chat tools are dropped and idle Myra runs abort after 120 seconds #709

Problem

A newly provisioned Myra agent advertises 11 pinned tool packages—including @corbits/mcp-tools@0.0.11—but receives an empty runtime tool set. For a request such as “What are the tools that are connected in here?”, it writes mcp_list_servers as ordinary assistant text instead of invoking a structured tool call. About two minutes later, the underlying workflow fails with aborted.

This reproduces after deleting the local Workbench database and Hub data, restarting Hub + Sidecar, connecting Anthropic again, and creating a fresh Myra workbench. It is not stale data or a provider-key problem.

Reproduction

1. Start current main with an empty database and a new HUB_DATA_DIR.
2. Connect an Anthropic provider and open the freshly provisioned Myra agent.
3. Send: What are the tools that are connected in here?
4. Observe Myra reply with prose ending in mcp_list_servers, rather than a tool invocation.
5. Wait 120 seconds from the first StepStarted.

Observed evidence

For the fresh failing deployment:

• workflow_run_launch_spec.tool_package_pins contains 11 entries, including @corbits/mcp-tools@0.0.11.
• The emitted workflow definition has toolFactoryIds: [].
• The sidecar's per-step deploy directory has no deploy/tool-packages-manifest.json; its loader therefore materializes an empty tool set.
• The durable log records RunStarted and StepStarted, then SignalAwaited with parkKind: "input" after the text reply; exactly ~120 seconds after StepStarted, it records StepFailed { message: "aborted" } and RunFailed.
• The chat turn is displayed as completed after the text reply even though its workflow later fails.

Root cause

Two wiring defects combine here.

1. Provisioned deployments persist tool pins but discard them at deploy time. prepareProvisionedDeployment() stores toolPackagePins in workflow_run_launch_spec, but deployReadyAllocation() reloads that spec and calls deployPreparedCodeSourcedWorkflow() without forwarding spec.toolPackagePins. The prepared-deploy parameter type has no pin field, and that deploy path never stages the per-step deploy tree. The existing stageWorkflowStep() path is the one that resolves pins into a manifest and sends the deploy pack. Consequently the sidecar's materializeStepTools() reads an absent manifest and legitimately returns no factories.

2. The assistant step timeout covers idle input waits. packages/seeding/src/seed.ts gives the assistant a 120,000 ms step timeout. In vendor/intx/workflow/src/runtime/run.ts, runStep() arms that timer before the first invokeStep(), then reuses the same abort signal while parkOnSignal() waits for the next input of an unbounded step. The timer is neither cleared after a successful turn nor scoped to an active model/tool invocation, so an otherwise healthy agent is aborted while waiting for its next message.

Expected behavior

• A fresh Myra deployment materializes every pinned tool package and exposes its tools as structured tool calls.
• After producing a reply, an unbounded chat agent remains parked and routable for the next message; idle time must not consume the model-turn timeout.
• Actual inference/tool work remains bounded by the configured per-turn timeout.
• The UI must not present a terminally failed workflow as a successfully completed turn.

Done when

• A deploy-level regression test proves pins persisted in workflow_run_launch_spec are forwarded into per-step staging, producing a deploy manifest and non-empty runtime factory IDs for @corbits/mcp-tools.
• A fresh provisioned Myra run invokes an MCP tool structurally for the reproduction prompt; it does not emit a literal tool name as assistant text.
• A runtime regression test proves an unbounded step that replies and then parks on input survives past its per-turn timeout, while a truly hung invocation still times out.
• Browser verification covers the fresh-provider, fresh-agent flow and shows no later RunFailed after the agent is idle.