Desktop: "Suggested task" chip card always defaults to "Start with worktree" - saved spawn-target preference regressed (~Jul 21)
Describe the bug
Since ~2026-07-21 the "Suggested task" popup card in Claude Code Desktop (background task suggestions created via the spawn_task tool) always shows "Start with worktree" as the primary action of its split button. "Start locally" only exists in the dropdown, and the choice is not remembered - the next chip is back to "Start with worktree".
Until ~Jul 20 the primary action reflected the persisted target preference (epitaxy-spawn-task-target-v2, values local/worktree/cloud/here, menu items with checkmarks). Users who had chosen "Start locally" got local starts by default. That preference is still stored in claude_desktop_config.json (preferences.epitaxyPrefs) but the card no longer reads it, and a selection made in the dropdown is no longer persisted anywhere.
Steps to reproduce
- Have any session create a task suggestion via the
spawn_tasktool. - On the chip card, open the dropdown next to "Start with worktree" and pick "Start locally".
- Let the next chip appear.
- The primary action is "Start with worktree" again - the explicit choice was not persisted (reproduced 10+ times).
Expected behavior
Remember the last explicitly chosen start target (the pre-Jul-21 behavior), or offer a setting to disable defaulting to worktrees for local sessions.
Environment
- Claude Desktop 1.24012.9 (Windows 11 Pro)
- Web frontend build 2026-07-25
- Bundled Claude Code CLI 2.1.219
3 Comments
Additional suggestion: the
spawn_tasktool (which creates these suggestion chips from within a session) currently only acceptstitle,tldr,prompt, andcwd- the chip creator has no way to influence the start target. An optionaltargetfield (e.g.local|worktree|cloud) would let the creating session pre-select a sensible default for the chip's primary action. That would complement the remembered-preference fix above: the user's remembered choice (or the chip's declared target) should win over a hardcoded worktree default.Still happening on macOS today (macOS 26.6.2, Claude Desktop 2.9939.4, Claude Code 2.1.281). And there's a case where the forced default doesn't just cost a click, it always fails.
I have a repo where worktrees make no sense (a big notes vault synced across machines), so its
.claude/settings.jsonhas aWorktreeCreatehook that deliberately exits 1. Every chip for that repo defaults to "Start with worktree", and clicking it gives a bare "Error". The app knows exactly why:~/Library/Logs/Claude/main.loghasWorktreeCreate hook failed: <the hook's message>thenWorktree creation failed with error: worktree_hook_failed, aborting session. None of that reaches the card.What would fix it, simplest first:
WorktreeCreatehook refuses, fall back to "Start locally", or respectworktree.bgIsolation: "none"as #94263 asks.+1 to the
targetfield onspawn_tasksuggested above too.Same on macOS with a folder of markdown notes: "Start locally" works, but it's an extra dropdown click on every spawn, and a worktree start silently misses uncommitted edits. +1 to a
targetfield onspawn_task, and to remembering the last pick / honoringworktree.bgIsolation: "none"(#94263).Workaround for anyone hitting this meanwhile: a project-level
WorktreeCreatehook that exits 1, as mentioned above. In.claude/settings.json:Tested: clicking "Start with worktree" now shows "Couldn't start the suggested task" (the chip stays), and "Start locally" opens normally. It doesn't fix the default, it just makes the wrong click harmless instead of silently starting in a worktree without your uncommitted edits. It affects anything else that creates worktrees in that project too.