Tasks: project-default preset always dispatches to the primary host, fails for projects on other machines

[mosmanlaw]

Summary

A Tasks dispatch preset with environmentKind: "project-default" (no machine) always spawns on the primary host. When the task's BB project has no local-path source on the primary host (its folder lives on another enrolled machine), dispatch fails with:

HTTP 404: Project has no local-path source for host

So a single preset like "Opus · high" cannot serve projects that live on different machines. The only workaround is one preset per machine (environmentKind: "new-worktree" + machineId), which multiplies the preset list by the number of machines.

Where

• plugins/tasks — presetSpawnEnvironment returns { type: "project-default" } for project-default presets.
• server — resolveProjectDefaultThreadEnvironment always uses requireConnectedPrimaryHostId(deps) and then resolveProjectWorkspaceTarget({ hostId, projectId }), which 404s when the project has no source on that host.

Seen on 0.44.0 and 0.44.1-nightly.36327831681.1.

Repro

1. Two enrolled machines: the primary host A and machine B.
2. BB project P with a single local-path source on B (isDefault: true), git repo.
3. Tracker project linked to P, any task, preset with environment project-default.
4. bb tasks dispatch <task> --preset <preset> → HTTP 404: Project has no local-path source for host.

Expected

project-default should resolve to the host of the project's default source (or any source) when the primary host has none — the same way a new thread in that project would start on the machine where the project lives. Projects with a source on the primary host keep today's behavior.

Local workaround

We patched the bundled tasks plugin: when the project has no source on the primary host, spawn with { type: "host", hostId: <default source host>, workspace: { type: "managed-worktree", baseBranch: { kind: "default" } } }, falling back to { type: "unmanaged", path: <source path> } if the worktree cannot be created. Fixing it in resolveProjectDefaultThreadEnvironment would cover every caller, not only Tasks.

[SawyerHood]

Report: https://get-bb.github.io/reports/issues/4446.html

REPRODUCED in two clean checkouts using actual Tasks delegation/storage and the server API with synthetic hosts. Project-default returns the reported 404 for a secondary-only project; explicit-secondary and primary-project controls succeed with the expected provisioning destinations. Real remote worktree/model execution was not exercised.