Repository navigation
Scheduled tasks: let schedule_task choose the workspace (or honour the project's defaultThreadEnvMode) #19786
Closed as not planned
Description
Today an unbound (fresh-thread-per-run) scheduled task always prepares a new worktree from origin/main
(scheduledTaskWorkspaceStrategy() returns {type: worktree, baseRef: "main", startFromOrigin: true}), and the
project's defaultThreadEnvMode is ignored. For frequent schedules that only read state and call tools
(every 10 min / hourly), each run pays a git fetch + a full checkout before it starts.
Measured on one workstation over 24 h: 141 new worktrees, 29 min of preparation wait in total, p90 prep 131 s
for a 10-minute schedule, and 3 runs lost when the fetch timed out during a short network outage.
Ask (either would do):
- A
workspaceStrategyfield on schedule_task / update_scheduled_task, the same shape as t3_thread_launch
(root | worktree | existing_worktree), used for each fresh run; or - Honour the project's defaultThreadEnvMode (local -> run in the project root) for unbound schedules.
Also useful: clean up the run's worktree when the scheduled thread settles and the tree is clean.
Related: #16183 (hard-coded main baseRef for fresh-thread schedules), #16725.
Activity
juliusmarminge commentedon Oct 15, 2026
Note
Grok responding on behalf of Julius.
Thanks for the numbers. This is a feature request, so it belongs in Ideas; we'll move it there. A fresh worktree per run for unbound schedules is the current intended behavior (see #16725). Until
schedule_taskcan pick a workspace, a schedule created in Settings can use "Use the project checkout" to run in the project root, and the hard-codedmainbase ref is tracked in #16183.elkasab99 commentedon Oct 16, 2026
Adding a harder failure mode to this: for projects whose root is not a Git repository, unbound scheduled tasks don't just pay worktree prep — every run fails.
T3 Code v0.1.0 (Linux, web). A task created via MCP
schedule_task(webhook trigger,bindToCurrentThread: false) is stored with{"type":"worktree","baseRef":"main","startFromOrigin":true}, and each run ends with:Setting the project's
defaultThreadEnvModetolocalhas no effect, andschedule_task/update_scheduled_taskhave noworkspaceStrategyfield, so MCP-created tasks can only be fixed in the web editor ("Use the project checkout" →{type:"root"}), which works. Normal threads fall back to local for non-Git projects (resolveSendEnvMode); the scheduler passes the stored strategy tothreadLaunch.launchwithout that fallback.Either option from the issue would fix it; a non-Git fallback to
rootwould at least stop the hard failure.t3dotgg commentedon Oct 21, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Thanks for the report. This behavior is intended, so we will not change it. If you need different behavior, please post the idea in Ideas discussions so others can vote on it. If you see a different fault, please open a new issue with steps to reproduce it.