[Bug]: Scheduled tasks that launch a fresh thread always branch from `main` and fail every run in repos without it#16183

opened17d agobyCcoygeek

Summary

A scheduled task created through the Orchestrator MCP schedule_task tool that launches a fresh thread per run (bindToCurrentThread: false, or a projectId other than the caller's, which defaults to unbound) always provisions that thread's worktree from a hard-coded baseRef: "main" with startFromOrigin: true. In a Git project whose default branch is not main (for example master or trunk) and which has no main branch locally or on origin, every run creates a new top-level thread whose only run fails at workspace preparation with git worktree add failed. The scheduler records each of these runs as lastRunStatus: "succeeded", so the task stays enabled and keeps producing failed threads without any signal in the task list or to the scheduling agent.

Steps to reproduce

Known case, not executed end-to-end against a running T3 server:

Open a Git project whose only branch is master, with an origin remote that also has only master.
From an agent thread in that project, call schedule_task with {"title":"Hourly check","prompt":"Report repository status.","schedule":{"type":"interval","everyMs":3600000},"bindToCurrentThread":false}.
Call run_scheduled_task_now with the returned task id, or wait for the next interval.
Open the thread created by that run, then call list_scheduled_tasks.

The git commands the launch path issues for step 3 were executed in a disposable repository with the same shape (bare origin containing only master, plus a clone):

shell

1	$ git remote get-url origin # exit 0
2	$ git fetch --quiet origin '+refs/heads/main:refs/remotes/origin/main'
3	fatal: couldn't find remote ref refs/heads/main # exit 128; code then falls back to `git fetch origin` (exit 0)
4	$ git show-ref --verify --quiet refs/remotes/origin/main # exit 1, so the local baseRef "main" is used
5	$ git -c checkout.workers=0 worktree add -b t3code/abc123 ../wt/t3code-abc123 main
6	fatal: invalid reference: main # exit 128
7	$ git symbolic-ref refs/remotes/origin/HEAD
8	refs/remotes/origin/master
9	$ git -c checkout.workers=0 worktree add -b t3code/ok ../wt/t3code-ok master
10	Preparing worktree (new branch 't3code/ok') # control, exit 0

A repository with only trunk and no remote fails the same worktree add ... main with fatal: invalid reference: main.

Expected behavior

The schedule_task tool description promises that an unbound task launches a working fresh thread per run: "use false only when the user wants a fresh top-level thread per run. Elsewhere each run launches a fresh thread." The tool exposes no base-branch parameter and says nothing about a main branch being required, so a fresh-thread run in a valid Git project with a different default branch should start its agent in a usable workspace.

Actual behavior

By static trace of the supported entry point: schedule_task stores { type: "worktree", baseRef: "main", startFromOrigin: true } for every unbound task, and update_scheduled_task re-applies the same value whenever bindToCurrentThread is passed. Each run calls ThreadLaunchService.launch, which returns after dispatching thread creation and forking workspace preparation into the background. Preparation finds no origin/main, keeps the literal local main, and runs git worktree add -b t3code/<id> <path> main, which fails as shown above. The thread receives a "Workspace preparation failed" item ending in git worktree add failed (stderr is dropped; see #4380). Because launch already returned, the scheduler's Effect.exit is a success, and it records lastRunStatus: "succeeded" with lastRunError: null, re-arms nextRunAt, and leaves the task enabled. The Settings badge and the list_scheduled_tasks summary both show success. Runtime reproduction through a running T3 server was not executed.

Evidence

Expected source: schedule_task tool description in apps/server/src/mcp/toolkits/orchestrator/tools.ts:100.
Failure source: hard-coded strategy in apps/server/src/mcp/OrchestratorMcpService.ts:196-201 used at L1348 (create) and L1420 (update); background preparation fork in apps/server/src/orchestration-v2/ThreadLaunchService.ts:680 with the origin fallback at L333-367; scheduler status at apps/server/src/scheduledTasks/ScheduledTaskService.ts:557; the git transcript above.
Evidence provenance: static
Local verification: static-proof
Reproduction completeness: complete

Runtime reproduction through T3 was not run. The static proof covers the reachable path from the MCP tool: the default at OrchestratorMcpService.ts:1322-1324 makes any other-project projectId unbound; ScheduledTaskService.upsert stores the strategy without validation; GitVcsDriverCore.fetchRemote falls back to a plain fetch on a missing remote ref; remoteBranchExists is false; and createWorktree passes the unresolved main to git worktree add. The git commands were executed directly and produced the failures shown. The Settings UI scheduling path also defaults its base to main (apps/web/src/components/settings/ScheduledTasksSettings.tsx:595) but lets the user pick another branch, so it is not a clean control. GitVcsDriverCore.resolveDefaultBranchName already exists in the server.

Restoration check

Using the reproduction above (a master-only project with a master-only origin), an unbound scheduled run currently yields a thread whose run failed at workspace preparation with git worktree add failed, while the task reports lastRunStatus: "succeeded". After the fix, the same run starts its agent in a prepared worktree (in this fixture, from master). Control: a project that does have main must still prepare its fresh-thread runs from main, and bound tasks (bindToCurrentThread: true) must keep posting into the calling thread without a worktree.

Additional context

The scheduler records whether a run was dispatched, not whether its thread was prepared, for both bound and unbound runs; no contract text defines lastRunStatus, so this report treats the misleading "succeeded" status only as a consequence that hides the failure, not as a separate defect. Workarounds available today: use bindToCurrentThread: true (runs share the calling thread's context and checkout and queue behind its activity), or edit the task in Settings, Scheduled tasks, and pick a real base branch (a later update_scheduled_task that passes bindToCurrentThread resets the base to main). A non-Git project with an unbound schedule also fails every run at the same preparation step, with "Failed to resolve the VCS driver for this Git command."; that may share the restoration but was not traced further. Related: #4380 (git stderr discarded), discussion #6866 (configurable default base branch for new worktree threads).

Area

apps/server

Impact

Major degradation or frequent failure. Every fresh-thread run of an MCP-created schedule fails in Git projects without a main branch, and the scheduler records each run as succeeded, so failed threads accumulate unnoticed.

Version or commit

main at 6f9cea00ae967f38fa3cdc9c07f92031806f4264.

Environment

Source inspection of pingdotgg/t3code main at 6f9cea00ae967f38fa3cdc9c07f92031806f4264. Git behavior checked with git 2.56.0 on macOS with global and system config disabled. The T3 server itself was not run.

Workaround

Editing the task's base branch in Settings, or binding runs to the calling thread, avoids the failure today, at the cost of manual per-task setup or giving up per-run fresh threads.

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

AAyushlm1015d ago

The same hard-coded strategy also breaks the "No project" (scratch) project. That project isn't a git repository, so creating a worktree fails no matter which base branch is used.

Repro on T3 Code Nightly 0.0.46-nightly.20261007.2761, macOS 26.4.1, with a Claude Code agent:

From an agent thread, call schedule_task with projectId set to the No project (scratch) project, bindToCurrentThread: false, and an interval schedule.
Call run_scheduled_task_now.

The run's thread fails before the agent starts:

1	Workspace preparation failed during provision worktree: Git command failed in GitWorkflowService.remoteExists (~/.t3/scratch): Failed to resolve the VCS driver for this Git command.

run_scheduled_task_now and list_scheduled_tasks still report lastRunStatus: "succeeded", as this issue describes.

The cause is scheduledTaskWorkspaceStrategy in apps/server/src/mcp/OrchestratorMcpService.ts. It returns { type: "worktree", baseRef: "main", startFromOrigin: true } for every unbound task, whatever the project is.

Setting the task's Workspace to Project checkout in Settings → Scheduled tasks works around it. The next run got its own scratch folder and completed.

Resolving the workspace from the project would fix both cases. For a project that isn't a git repository, that means running in the project folder.

Jjlipworth13d ago

Another case: a repo whose only remote isn't named origin. In mine the remote is gitlab (gitlab/HEAD -> gitlab/<default>), there's no main anywhere, and an unbound weekly task failed with the same git worktree add failed.

With #16215 as it stands, I think this repo works, but only by luck:

resolveDefaultBranchName(workspaceRoot, "origin") finds nothing, so the PR falls back to the branch currently checked out in the root. That happens to be the default branch here. If the root were sitting on a feature branch, every scheduled run would branch from that feature branch.
ThreadLaunchService.ts:336 turns startFromOrigin off when there's no origin remote, so these runs never fetch. They start from the local branch even though the task asked to start from the remote.

Possible fix: when origin doesn't exist, use the branch's upstream remote, or the only remote if there's just one, both for finding the default branch and for the fetch.

Ffilipenevola8d ago

Another case: a regular registered project (not Scratch) whose root is a plain folder containing several git repos as subfolders. #17451 doesn't cover this; per the triage on #18615, plain non-git project folders are out of scope there.

T3 Code Nightly 0.0.46-nightly.20261009.2873, macOS 26.6.2, Claude agent.

Setup:

Project workspaceRoot = <ws>/quaveone, with no .git. The repos live in <ws>/quaveone/web, <ws>/quaveone/infra, and so on.
The project has repositoryIdentity: null and defaultThreadEnvMode: null.
A weekly fixed_time task was created with schedule_task. It is unbound (boundThreadId: null).
The prompt itself creates its own side worktree in the web subfolder with git -C <ws>/quaveone/web worktree add …. It only needs T3 to start the thread in the project root.

The 2026-10-14 08:00 UTC run failed about 30 ms after it was requested, before the agent started (startedAt: null):

1	Workspace preparation failed during provision worktree: Git command failed in GitWorkflowService.remoteExists (<ws>/quaveone): Failed to resolve the VCS driver for this Git command.

list_scheduled_tasks still shows lastRunStatus: "succeeded" for the task, and nothing notified anyone. The only sign of the failure was a new thread in failed status. For a weekly job, that means a whole week of work gets skipped without anyone noticing.

Suggested fix: when the project root isn't a git work tree, treat the strategy as root, the same coercion #17451 does for Scratch, but based on whether the folder is a git repo rather than whether it is Scratch. This multi-repo "workspace folder" layout seems common for agents that manage their own worktrees.

Rrdbell5d ago

Confirmed end to end on T3 Code 0.1.0 (Linux, Claude agent), in a repo whose only branch is master (origin/HEAD -> origin/master, no main locally or on origin).

The task was created bound to the calling thread (the default). Runs worked.
update_scheduled_task was called with bindToCurrentThread: false and a new fixed_time schedule. The stored workspace strategy became {"type":"worktree","baseRef":"main","startFromOrigin":true} (the update path noted in #16577).
Both following runs failed at workspace preparation with Git command failed in GitVcsDriver.createWorktree (...): git worktree add failed, with no reason tag. Running the same git worktree add -b <branch> <path> main by hand gives fatal: invalid reference: main (the case #17794 tags).
list_scheduled_tasks still reports lastRunStatus: "succeeded" (#18213).

A new thread started from the UI in the same project gets a worktree normally, so only the scheduled-task strategy is affected.

JJulius Marminge1d ago

Reproduced on e27a03e94d: a scheduled task launching a fresh thread in a repository whose default branch is master failed with ref_not_found. #22801 (GitCafe 22800) resolves the project's default branch instead of assuming main; on a real server both a fresh-thread schedule and an explicit unbind completed from master, and an independent rebuild of the run matched. Existing saved tasks are not migrated. Desktop, mobile and other connection modes remain unverified.

Ccoygeek15h ago

Keeping this open: both current main (96bae546) and stable v0.1.1 still store baseRef: "main" for fresh-thread MCP schedules, including explicit unbinding, so the original master-only case remains. #22801 addresses this but is still open and unmerged; the successful verification described above applies to that PR. #17451 is released in v0.1.1 and fixes the Scratch subcase only. This recheck was source-based, not a new live-server reproduction.