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
A reserved task launch whose sanitize fails, and whose reclaim then also fails, can still start MCP in the unsanitized checkout. Discovery and sends for that checkout should stay closed until it is sanitized or physically removed.
Background
This was deferred from #4673, Codex round 1 (threads PRRT_kwDOPxxmWM6mQTPL and PRRT_kwDOPxxmWM6mQTPM). #4673 moved init completion after reclaimUnsanitizedTaskCheckout. The two cases below existed before #4673; before it, init completed before any reclaim was attempted.
The unpublish fails or can't be verified. The row and the unsanitized checkout both stay. Init completes so that waiters don't hang. listWorkspaceMcpPrompts then re-reads the still-published metadata and can start the configured MCP server from that checkout, and any later request can do the same.
The row is unpublished but checkout deletion fails.rollbackFailedTaskCreate only logs the runtime.deleteWorkspace failure, so the reclaim reports success. A concurrent send or request that cached its metadata/runtime before waitForInit can continue once init state is cleared, and start MCP in the leftover checkout.
Proposed direction (needs design)
Record "unsanitized" per checkout, bound to the task attempt. MCP start and discovery (getToolsForWorkspace, getPromptsForWorkspace, listServers, getPrompt) and sends refuse that checkout until sanitize succeeds or the checkout is removed. Waiters should fail fast with a typed error instead of either hanging or proceeding. Make reclaimUnsanitizedTaskCheckout report failed physical deletion as not reclaimed.
Acceptance
Failed unpublish, then a prompts.list or send: no MCP process starts with its working directory in the unsanitized checkout, and the caller gets a typed refusal.
Failed deletion after unpublish: a request that was already parked in waitForInit does not start MCP in the leftover checkout.
Summary
A reserved task launch whose sanitize fails, and whose reclaim then also fails, can still start MCP in the unsanitized checkout. Discovery and sends for that checkout should stay closed until it is sanitized or physically removed.
Background
This was deferred from #4673, Codex round 1 (threads PRRT_kwDOPxxmWM6mQTPL and PRRT_kwDOPxxmWM6mQTPM). #4673 moved init completion after
reclaimUnsanitizedTaskCheckout. The two cases below existed before #4673; before it, init completed before any reclaim was attempted.listWorkspaceMcpPromptsthen re-reads the still-published metadata and can start the configured MCP server from that checkout, and any later request can do the same.rollbackFailedTaskCreateonly logs theruntime.deleteWorkspacefailure, so the reclaim reports success. A concurrent send or request that cached its metadata/runtime beforewaitForInitcan continue once init state is cleared, and start MCP in the leftover checkout.Proposed direction (needs design)
Record "unsanitized" per checkout, bound to the task attempt. MCP start and discovery (
getToolsForWorkspace,getPromptsForWorkspace,listServers,getPrompt) and sends refuse that checkout until sanitize succeeds or the checkout is removed. Waiters should fail fast with a typed error instead of either hanging or proceeding. MakereclaimUnsanitizedTaskCheckoutreport failed physical deletion as not reclaimed.Acceptance
prompts.listor send: no MCP process starts with its working directory in the unsanitized checkout, and the caller gets a typed refusal.waitForInitdoes not start MCP in the leftover checkout.tests/fixtures/mcp/recording-server.ts).Refs #4673, #4576
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:high• Cost:$253.94