[Bug]: "workspace preparation failed" on scheduled task for "no project" #17309

Activity

1. bzbetty

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 8, 2026
2. juliusmarminge commented on Oct 8, 2026

   

   juliusmarminge

   on Oct 8, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the report — this looks real on current main (580948708).

   What happens

   A scheduled task stores workspaceStrategy on the row and, when unbound, launches with that strategy as-is (ScheduledTaskService.runTask → threadLaunch.launch, ~L798–805). The schedule editor defaults new tasks to Create a new worktree (EMPTY_DRAFT.workspaceMode: "worktree", ScheduledTasksSettings.tsx ~L127) and still lists the Scratch project titled No project as an ordinary project (ManagedProjectFolders bootstraps it with that title). There is no UI or upsert guard that forbids worktree/checkout modes for Scratch.

   At run time, type: "worktree" always calls git.createWorktree against project.workspaceRoot (ThreadLaunchService.prepareInBackground, ~L321–404). Scratch is not a git repo (ManagedProjectFolders.ts header: Scratch is a plain folder with per-thread subfolders). That most likely fails and surfaces as Workspace preparation failed (failureDetail, ThreadLaunchService.ts ~L165–171).

   The path that does work for No project is type: "root": launch remaps Scratch root launches into a fresh per-thread folder via managedFolders.folderForThread (ThreadLaunchService.ts ~L746–763).

   Open PR #17257

   Web-only: adds an explicit No project choice, hides workspace/base-branch/checkout controls for that choice, and on save forces { type: "root" } via workspaceStrategyFromDraft(draft, noProject). That should stop new UI saves (and a re-save of an existing Scratch task) from storing worktree mode.

   It does not fully close this on its own:

   • no server coerce/ignore of a stored worktree strategy for Scratch / non-git cwd at upsert or run time
   • MCP schedule_task still hard-codes unbound tasks to { type: "worktree", baseRef: "main", startFromOrigin: true } (OrchestratorMcpService.scheduledTaskWorkspaceStrategy, ~L228–233) — same failure already noted on #16183

   Suggested fix

   1. Land / extend #17257 for the UI.
   2. Server-side: when the target is Scratch (or cwd is not a git repo), coerce worktree / invalid checkout strategies to root (or reject with a clear error) on upsert and at launch, so existing tasks and MCP don’t keep failing.
   3. Teach MCP schedule_task to pick root for Scratch / non-git projects (overlaps #16183).

   Workaround: edit the task → Workspace → Use the project checkout (root), then run again.

   Related (same Scratch + git-worktree mismatch, different entry): #16183. Nearby No-project threads but different bugs: #17166, #17187.

   I traced this on main only — I did not run a scheduled task end-to-end.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 8, 2026
4. Alb11747 commented on Oct 9, 2026

   

   Alb11747

   on Oct 9, 2026

   More actions

   Confirmed end-to-end on T3 Code 0.0.46-nightly.20261008.2849, Windows x64, at 2026-10-09 03:14:17 UTC. This adds a live MCP reproduction to the source analysis above.

   Minimal reproduction

   1. Start a conversation under No project (the managed Scratch project).

   2. Call schedule_task from that conversation with:

      {
        "title": "Repro: no-project scheduled fresh thread",
        "prompt": "Reply exactly SCHEDULER_REPRO_OK. Do not use tools or do any other work.",
        "schedule": { "type": "interval", "everyMs": 86400000 },
        "bindToCurrentThread": false,
        "enabled": false
      }

   3. Call run_scheduled_task_now with the returned task ID. The disabled schedule permits a manual run without leaving recurring work active.

   4. Inspect the newly created thread with t3_thread_list / t3_thread_read, or open it in the app.

   Expected

   The scheduler opens a fresh Scratch conversation in its own folder and runs the prompt, without requiring a Git repository.

   Observed

   The task is accepted with boundThreadId: null, but its new thread immediately fails with Workspace preparation failed:

   Workspace preparation failed during provision worktree: Git command failed in GitWorkflowService.remoteExists (C:\Users\<user>\.t3\scratch): Failed to resolve the VCS driver for this Git command.
   

   Durable run state confirms status: "failed", startedAt: null, and no assistant response. The thread was created at 03:14:17.205Z and failed at 03:14:17.673Z; the provider never started. The user's screenshot also shows the same error in the No project conversation.

   run_scheduled_task_now and the task list report lastRunStatus: "succeeded" and runCount: 1 despite the failed thread. That result reflects successful dispatch/bookkeeping, as documented by the tool; it does not prove the provider ran.

   Source corroboration

   Read-only inspection of local main at 3143335fc3a568cbbb5174764961889272135cb9 (distinct from the running release version) confirms:

   • apps/server/src/mcp/OrchestratorMcpService.ts:230–235 assigns every unbound MCP task { type: "worktree", baseRef: "main", startFromOrigin: true }, without considering the Scratch target.
   • apps/server/src/scheduledTasks/ScheduledTaskService.ts:797–805 passes that stored strategy to threadLaunch.launch.
   • apps/server/src/orchestration-v2/ThreadLaunchService.ts:746–765 allocates a per-thread Scratch folder only for type: "root" launches.

   This verifies the MCP entry path identified above. I did not exercise the settings editor or test the proposed root-mode workaround. PR #17257 is still open at the time of verification.

   The temporary schedule was kept disabled throughout the reproduction and removed afterward; the failed thread was retained for inspection. No source changes were made.

   Verification and report by GPT-6.1 Sol through the Codex harness in T3 Code.