Suggested task ("task chip") intermittently fails to start, with no surfaced error and no log

Summary

Clicking Start with worktree on a suggested task chip intermittently fails.
The only feedback is a toast reading Couldn't start the suggested task. There
is no error detail in the UI, and I could not find any log on disk that records
the underlying failure.

The intermittency is not the main complaint — the absence of any diagnosable
error is. When it happens there is nothing for the user to act on, so every
occurrence is a dead end.

Environment

| | |
|---|---|
| Claude Code | 2.1.268 |
| Surface | Desktop app, Code tab |
| OS | macOS 15.7.4 (build 24G517), Darwin 24.6.0, Apple Silicon |
| git | 2.39.5 (Apple Git-154) |
| Model | Opus 5 |

Steps to reproduce

Not reliably reproducible — it happens occasionally, across sessions.

1. In a session, have the assistant file a suggested task (a "chip") via the

task-suggestion tool.

1. Click Start with worktree on the chip.
2. Occasionally: the toast Couldn't start the suggested task. appears and no

session is created.

The chip that failed was filed from a session whose working directory was a
git worktree (<repo>/.claude/worktrees/<name>) rather than the main
checkout. A re-filed chip that explicitly targeted the main checkout did start
successfully — but that attempt was also simply a retry, so I cannot
attribute the success to the directory. n=1 on each.

Expected

Either the task starts, or the failure names a cause the user can act on
(permission, path, git state, disk, network), and the underlying error is
written somewhere inspectable.

Actual

A single toast with no detail:

⚠ Couldn't start the suggested task.

<img width="602" height="138" alt="Image" src="https://github.com/user-attachments/assets/e3b53b7f-308d-4bc0-a4c9-7f96b3cae587" />

No log found. I searched ~/Library/Logs and ~/Library/Application Support
for anything Claude-related modified around the failure and found nothing that
captured it.

Causes ruled out

Worth recording so this isn't chased at the git layer — none of these is the
problem:

• Creating a worktree from inside a worktree works. git worktree add run

from a worktree returned exit 0.

• So does a nested target. git worktree add pointing underneath the

current worktree also returned exit 0.

• No stale worktree registry. git worktree prune --dry-run reported

nothing prunable, with 30 worktrees registered.

• Not disk. 487 GiB free.
• Working tree was clean at the time of the failure.

What would help

1. Surface the underlying error in the toast, or behind a "details" affordance.
2. Write the failure to a log file with a documented location.
3. If the spawn has a precondition on the session's working directory being a

main checkout rather than a worktree, fail with that message explicitly —
or handle the worktree case.

I can supply the local session and task identifiers privately if they help
correlate telemetry; I have left them out here deliberately.