Teardown scripts are skipped when a workspace is deleted via MCP/CLI/SDK (force: true is hardcoded) #6174

Activity

1. github-actions commented on Aug 5, 2026

   

   github-actionsBot

   on Aug 5, 2026 – with GitHub Actions

   Contributor

   More actions

   The report reproduces from the code. Here's my triage:

   ---

   Confirmed by reading the code — this is a real behavioral gap, and the root cause identified in the report is exactly right.

   Summary

   .superset teardown commands only run on the interactive delete path. Desktop and mobile call workspaceCleanup.destroy with force defaulting to false, so teardown executes; every programmatic surface (MCP workspaces_delete, superset workspaces delete, SDK workspaces.delete) funnels through the legacy workspace.delete procedure, which hardcodes force: true. Since force is the same flag that means "skip teardown", the documented "delete workspace → teardown commands run" contract is unreachable from any non-UI caller, and because teardown is skipped rather than attempted-and-failed, warnings stays empty and nothing is logged — the caller gets a clean {"success":true,...,"warnings":[]} while externally provisioned resources leak.

   Affected code

   • packages/host-service/src/trpc/router/workspace/workspace.ts:159-169 — workspace.delete hardcodes force: true:

     return destroyWorkspace(ctx, {
         workspaceId: input.id,
         deleteBranch: false,
         force: true,
     });

   • packages/host-service/src/trpc/router/workspace-cleanup/workspace-cleanup.ts:237 — teardown is gated on if (!input.force && local && project), and the doc comment at :136-138 states force "skips teardown (step 1)".
   • Callers of the forced path:
     • packages/mcp/src/tools/workspaces/delete.ts:33 — "workspace.delete", no force in inputSchema
     • packages/cli/src/commands/workspaces/delete/command.ts:34
     • packages/sdk/src/resources/workspaces.ts:122
   • Callers of the correct path (teardown runs): apps/desktop/src/renderer/hooks/host-service/useDestroyWorkspace/useDestroyWorkspace.ts:71-75 (force: input.force ?? false) and apps/mobile/.../useWorkspaceHeaderActions.ts:83-91.

   Root cause

   One flag carries two unrelated meanings in runDestroy. force is used both for "the user consented to destructive git semantics" (skip the dirty-worktree preflight at :201, --force --force on worktree removal at :278-281) and for "skip the user's teardown script" (:237). The legacy external surface wants only the first — its intent is a non-interactive contract that can't stop to prompt about uncommitted changes — but it inherits the second for free. Nothing in runTeardown is at fault: packages/host-service/src/runtime/teardown/teardown.ts:54 is simply never called on this path, which is also why host-service.log shows no trace.

   Note the legacy in-process desktop path at apps/desktop/src/lib/trpc/routers/workspaces/procedures/delete.ts:222-259 models this correctly: it always runs teardown and uses force only to decide whether a teardown failure blocks the delete.

   Reproduction

   Integration-test sketch, closely following the existing packages/host-service/test/integration/teardown.integration.test.ts and workspace-create-delete.integration.test.ts fixtures:

   // Create a feature worktree scenario whose repo has
   // .superset/config.json → { "teardown": ["touch $PWD/teardown-ran"] }
   const scenario = await createFeatureWorktreeScenario({
       hostOptions: { apiOverrides: cloudFlows.workspaceDeleteOk() },
   });
   
   await scenario.host.trpc.workspace.delete.mutate({
       id: scenario.featureWorkspaceId,
   });
   
   // Fails today: teardown never runs on the external surface.
   expect(existsSync(join(someDurablePath, "teardown-ran"))).toBe(true);

   (Assert against a marker outside the worktree, since step 2b deletes the worktree directory.) Manually: any project with a teardown entry, delete via MCP workspaces_delete vs. the UI delete dialog and compare.

   Fix direction

   The cleanest fix is to split the two meanings rather than flip force wholesale — the external surface genuinely needs to bypass the dirty-worktree preflight, so force: false there would start rejecting deletes that currently succeed. Suggested shape:

   1. Add a third field to DestroyWorkspaceInput (e.g. skipTeardown: boolean) and gate :237 on that instead of input.force. workspaceCleanup.destroy maps skipTeardown: input.force to preserve the renderer's current force-retry contract; workspace.delete passes force: true, skipTeardown: false.
   2. On the non-interactive path, a teardown failure shouldn't hard-fail the delete (there's no caller to prompt for force-retry) — push it into warnings (Teardown failed (exit N): …) so the MCP/CLI/SDK response stops claiming a clean cleanup. That also fixes the "empty warnings looks successful" half of the report independently.
   3. Optionally expose force/skipTeardown on workspaces_delete's inputSchema so an agent can opt out deliberately.

   Two existing tests encode the current behavior and will need updating alongside: packages/host-service/test/integration/bug-hunt-3.integration.test.ts:130 ("workspace.delete forces removal through the v2 cleanup saga", asserts warnings is empty on a dirty worktree) and workspace-create-delete.integration.test.ts:394. Both should keep passing under the split above, since neither fixture configures a teardown — worth confirming resolveTeardownCommand returns null for them so teardown stays a no-op { status: "skipped" }.

   The docs at apps/docs/content/docs/setup-teardown-scripts.mdx:169-176 describe force-delete purely as a UI recovery affordance for a failed teardown, which supports reading the current programmatic behavior as unintended rather than a deliberate contract.
2. Kitenite commented on Aug 5, 2026

   

   Kitenite

   on Aug 5, 2026

   Member

   More actions

   Hey @eckelarsson thanks for reporting, fixing this immediately

   👍React with 👍1Reacted by Erik Larsson
3. Kitenite

   closed this as completedin #6176on Aug 5, 2026
4. heidihowilson

   added a commit that references this issue on Aug 5, 2026

   fix(host-service): run teardown scripts on CLI/SDK/MCP workspace dele…

   ...

   This issue will close once commit 2c87af3 is merged into the 'vision-pro-app' branch.

   2c87af3
5. Kitenite

   added a commit that references this issue on Oct 21, 2026

   fix(mobile): Codex stops scrolling after a terminal tab switch (#8737)

   ...

   fd842e3