worktree add: bound git probes and emit progress before long post-create steps

[chubes4]

Problem

studio wp datamachine-code workspace worktree add ... --skip-bootstrap can appear to hang and time out in an agent shell even though the worktree is created successfully.

Observed command:

studio wp datamachine-code workspace worktree add agents-api fix/provider-safe-runtime-tool-names-min --skip-bootstrap

The caller timed out after 120s with no output:

shell tool terminated command after exceeding timeout 120000 ms

But the worktree had been created:

handle: agents-api@fix-provider-safe-runtime-tool-names-min
branch: fix/provider-safe-runtime-tool-names-min
head: a61461d
created_at: 2026-06-08T19:45:16+00:00
state: active
dirty: 0

--skip-bootstrap was honored, so this was not dependency installation. The worktree also did not have the expected injected context files (AGENTS.md projection / .claude/CLAUDE.local.md), which suggests the command was killed after creating/storing lifecycle metadata but before final context injection / inventory / response output completed.

Likely cause

The worktree-add path does substantial silent work before returning:

• WorktreeStalenessProbe::fetch() runs git fetch --quiet origin with no timeout.
• Worktree add then runs several staleness/default-branch git probes without explicit timeouts.
• Context injection and inventory/hook work happen after creation but before the CLI prints the final response.
• WP-CLI emits no progress/checkpoints while the ability is running, so agent shells see no output until everything completes.

Relevant code:

inc/Workspace/WorktreeStalenessProbe.php
inc/Workspace/WorkspaceWorktreeLifecycle.php
inc/Workspace/WorktreeContextInjector.php

Why it matters

For coding agents, a no-output timeout looks like a failed/hung command even when the mutation actually landed. That creates ambiguity and risks duplicate worktree creation attempts or manual recovery work.

It is especially surprising with --skip-bootstrap: callers expect a quick bare checkout, but the command can still spend unbounded time in fetch/probe/context paths.

Desired behavior

1. Bound worktree add git probes with a timeout, especially git fetch --quiet origin.
2. Treat fetch/probe timeout like existing fetch failures where safe: continue with fetch_failed / staleness_unknown instead of blocking indefinitely.
3. Emit progress/checkpoints to CLI before long phases, for example:

Fetching origin for staleness check...
Creating git worktree...
Writing lifecycle metadata...
Injecting site context...
Updating worktree inventory...

4. Consider returning/printing the successful worktree creation result before optional post-create context/inventory hooks, or make post-create failures/timeouts clearly recoverable.

Acceptance criteria

• worktree add --skip-bootstrap cannot hang indefinitely on fetch/staleness probes.
• If a non-critical probe times out, the response still includes the created worktree path/handle plus a clear warning.
• CLI users and agents get visible progress before long-running steps.
• A killed/timeout post-create path does not leave ambiguous state without a clear recovery command such as worktree refresh-context <handle>.

Evidence from observed run

Worktree list confirmed creation after the timeout:

agents-api@fix-provider-safe-runtime-tool-names-min
path: /Users/chubes/Developer/agents-api@fix-provider-safe-runtime-tool-names-min
head: a61461d
created_at: 2026-06-08T19:45:16+00:00
liveness: live
state: active
dirty: 0

Context files were not present after the timeout, consistent with interruption before/during context injection.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.5)
• Used for: Observed the timeout, inspected DMC worktree lifecycle code and worktree metadata, and drafted this issue; Chris remains responsible for triage and implementation.