[brennanb2025]

	Files	Added	Deleted	Net
Test	14	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​1888	$\color{#cf222e}{\Huge{\mathbf{−}}}$​18	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​1870
Prod	27	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​1539	$\color{#cf222e}{\Huge{\mathbf{−}}}$​385	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​1154

ELI5

Creating a workspace sometimes takes minutes instead of seconds, and we can't tell from one machine whether the checkout Orca prepares in advance (the "spare") speeds creates up or slows them down for real users. This PR adds a few numbers to the event Orca already sends when a workspace is created (or fails to be), so that question can be answered. Nothing changes in what you see or do.

What Changed

The problem. On 2026-09-28 worktree creates took 80-268 s instead of 5-15 s. To save time, Orca builds a spare checkout in the background (when the new-workspace dialog opens, and again automatically after a create in a burst) so the next create can reuse it instead of checking out from scratch. That background work may also slow down creates running at the same time. A study on one machine and one repo size could not settle whether the spare helps or hurts on balance, because the answer depends on repo size, disk, platform, how many worktrees exist, and what else is running. #23699 (remove the spare, or keep it under tighter rules) is parked until we have real numbers.

User-facing change: none. Creates behave exactly as before. No new Git process runs on the create path, nothing new is waited on before the create answers, and every new value comes from data the create already had, plus one small file read of the repo's .git folder after the create has already returned.

What is added. The existing workspace_created and workspace_create_failed events get optional fields. They are numbers or fixed categories only: never a path, repo name, branch name, ref, or error text. Consent and opt-out work exactly as they already do for these events (same track() call, same consent check, same validator and rate caps).

On a successful create:

• total_ms, and unattributed_ms (wall-clock time no timed step covers).
• One duration per timed step, left out when the step didn't run: resolve_name_ms, refresh_base_ref_ms (the wait for the base fetch), git_worktree_add_ms, prepared_checkout_claim_ms (picking and reserving a spare, including its base and drift checks), prepared_checkout_wait_ms (waiting for an unfinished spare), prepared_checkout_finalize_ms (handing the spare over), prepared_checkout_discard_ms (removing a spare whose hand-over failed), list_created_worktree_ms, persist_metadata_ms, create_symlinks_ms, resolve_shared_directories_ms, resolve_worktreeinclude_ms, create_shared_directories_ms, copy_worktreeinclude_ms, prepare_setup_ms, spawn_startup_terminal_ms.
• Spare outcome: prepared_checkout = hit or miss.
• On a hit: prepared_checkout_reset (none, base_moved: the base moved since the spare was built or last refreshed, or retargeted: it was reset onto a sibling ref such as main vs origin/main), prepared_checkout_origin (prefetch: built when the dialog opened, rearm: built automatically after an earlier create, rearm_then_prefetch: built automatically and then also asked for by the dialog), prepared_checkout_build_ms (from when Orca started building the spare, including any wait for the base fetch it is built on, to it being ready; a later refresh doesn't restart it) and prepared_checkout_idle_ms (from its latest ready, after its build or a refresh, to this create taking it; 0 if the create waited for it).
• On a miss: prepared_checkout_miss_reason, a fixed reason (none_armed, repo_mismatch, base_mismatch, prepare_failed, finalize_failed, sparse_checkout, and so on).
• Context: create_entry_point (app for the Orca window, runtime for the CLI, phone app, agents, paired clients, orchestration and server automations), execution_host (local, wsl or ssh: where the create's Git ran), worktree_count_bucket (1, 2-5, 6-20, 21-100, 101-300, 301-1000, 1001+), repo_file_count_bucket (<1k, 1k-10k, 10k-100k, 100k-500k, 500k+ tracked files), concurrent_creates (the most other creates running at once during this one), concurrent_preparations (the most spare builds and spare clean-ups running at once during this create, not counting the spare it used), post_checkout_hook (present, absent, custom_hooks_path, unknown; the hook's content is never read): whether the repo has a post-checkout hook; every create runs it once, a normal checkout inside git worktree add (part of git_worktree_add_ms) and a reused checkout at hand-over (part of prepared_checkout_finalize_ms), so a slow hook can be told apart from a slow checkout.

On a failed create: failed_phase (the step it failed in, or untimed), total_ms (time until the failure), the same spare outcome fields as above plus prepared_checkout_wait_ms, and create_entry_point, execution_host, concurrent_creates, concurrent_preparations.

The public privacy page (docs/site/content/docs/telemetry.mdx) gets one sentence so its description of the workspace event stays accurate.

Mechanism.

• Both ways a create can start (the app's create handler and the runtime API used by the CLI, phone app, agents, paired clients, orchestration and server automations) begin one shared sender. It owns the step timer and sends exactly one event per create, on success or failure. Before this PR only the app path sent workspace_created; runtime creates used the spare too but sent nothing.
• The step timer is the one the create already used for its trace span. failed_phase is matched by the error itself: each timed step remembers the error it let escape, and the sender looks up the error it caught (following cause if it was wrapped), so a failure that was recovered from can't be mistaken for where the create died.
• The spare's own steps are timed separately inside git_worktree_add, so on a miss the plain checkout time is git_worktree_add_ms minus the prepared_checkout_* steps.
• An in-memory counter tracks creates in flight and spare work in flight (builds until they are ready, and background removals of expired or evicted spares). Each create records the most it saw at once, leaves out the spare it used, and stops counting when it finishes, so the replacement spare it starts at the end isn't counted against it.
• The spare pool already knew whether a spare was asked for by the dialog or built automatically; it now also notes when the dialog asks for an automatically built one, when its first build started and finished, and when it was last ready (after its build or a later refresh), all on the same monotonic clock as the step timer.
• After the create has returned, and only for local and WSL repos with telemetry on, a capped (2 s) file check reads .git/config and .git/config.worktree, stats .git/hooks/post-checkout, lists the .git folder once (to spot a split index), and reads the 12-byte header of .git/index for its entry count (the number of tracked files). The count is left out for a split index or whenever sparse checkout is on, where it isn't the file count. The same check lists .git/worktrees once and reads each entry's small locked file to count the worktrees, leaving out Orca's prepared checkouts the way the worktree listing does, because the create itself no longer lists worktrees (SSH creates still use their own listing).
• Sending the event never affects the create: if sending fails, the error is logged and the create's own result or error is returned unchanged.

What is recorded where.

• Every local, WSL or SSH create sends these fields, from the Orca window (dialog, in-app automations, work-item launches, session forks) and from the runtime API.
• SSH: there is no spare, the hook and file count aren't read (that would need a remote round trip), and name resolution and the base fetch land in unattributed_ms.
• SSH provisioned-root recipes still send their events without the new fields; adopting a provisioned root is a registration, not a create Orca times.
• Folder workspaces: the event is unchanged, since a folder "create" is a registration with nothing to time; runtime folder creates still send nothing.

Event counts change. workspace_created and workspace_create_failed counts rise from this release, because CLI, phone, agent, orchestration and server-automation creates now send them. Creates from a paired client run on, and are counted under, the host install. Filtering to create_entry_point missing or app reproduces the earlier series.

Reading the numbers.

• Step fields nest: the prepared_checkout_* steps sit inside git_worktree_add_ms, so never sum step fields; unattributed_ms already accounts for overlap.
• Compare the Orca window and the runtime on git_worktree_add_ms and its sub-steps, not on total_ms: runtime creates also spawn their terminals inside the create, and that time is in their unattributed_ms.
• The existing per-event rate cap (30 per event name, refilling at 0.5 per second) can drop the tail of a very large agent burst, and every event also counts toward the existing per-session ceiling of 1,000.

Compatibility. Every new field is optional, so payloads from older builds still validate, and additive optional fields are safe on an existing event. CreateWorktreeResult.timing gains optional fields that nothing on either side of the wire parses.

What this will tell us

• Whether reusing a checkout Orca prepared in advance makes creating a worktree faster or slower, and by how much for a typical create and a slow one, compared with creates that did a normal checkout.
• How long creates wait for a prepared checkout that isn't finished yet, how long one takes to build, and how long it sits ready before it's used.
• Whether prepared checkouts being built or cleaned up in the background slow down other creates running at the same time, for example when agents create several worktrees in a row.
• How often a prepared checkout is reused, whether it came from the dialog, from the automatic replacement after a create, or from that replacement which the dialog then asked for as well, what reset it needed before hand-over, and when it isn't reused, the fixed reason why.
• Where the rest of a create's time goes (updating the base branch, the checkout, copying files, starting terminals), and for a failed create, which step it stopped in and what the prepared checkout had done before it.
• How all of this differs by platform, by local, WSL or SSH repos, by how many files the repo tracks, and between the Orca window and the CLI, phone and agent interfaces.
• Whether the repo has a post-checkout hook; every create runs it once, a normal checkout inside git worktree add (part of git_worktree_add_ms) and a reused checkout at hand-over (part of prepared_checkout_finalize_ms), so a slow hook can be told apart from a slow checkout.
• Together, these decide fix(worktree): a create does one fetch and one checkout, and background work waits for it #23699: keep the prepared checkout under tighter limits, or remove it.

Why

We need real-world numbers before deciding what happens to the spare checkout. Extending the existing events, rather than adding a new one, keeps one row per create with its outcome, source and timing together, and inherits the existing consent and validation path unchanged.

Alternatives I considered:

• A new sibling event: a second row per create that has to be joined back to the first, and it would still leave the existing count missing CLI and agent creates. The registry calls for a new name only when a field is renamed or changes meaning, and nothing here does that.
• Duration buckets instead of milliseconds: buckets would hide the distribution we're trying to see (for example whether the spare wait is 200 ms or 20 s). A plain number carries no identifying information.
• Repo size from the .git/index byte size: the compact index format Git can use in large repos (feature.manyFiles) is about 40% smaller per file, which would skew exactly the repos we care about; the header's entry count is the same in every format.

Where this fits

The problem: creating a worktree took 80-268 s instead of 5-15 s on 2026-09-28. The plan to fix it:

Step	PR	What it does
1	#23699	A create does one fetch and one checkout (the spare checkout is removed); background disk work waits for a local create. Parked until this data exists.
2	planned, no PR yet	One worktree membership model per repo; no repeated git worktree list
2b	planned, no PR yet	The create card shows Git's checkout progress
3	#22356	PR conflict checks stop writing throwaway objects into the user's repo
(separate)	#23698	Local main is updated safely, once per repo and branch

This PR is the measurement step that #23699 waits on. It records how creates behave on main today, with no behavior change.

Linked Issue

N/A (maintainer).

Visual Proof

N/A: nothing visible changes. The create flow and UI are untouched.

Testing

• I manually tested these changes locally

• Automated tests added/updated

• Schema tests: full valid payloads for both events, old payloads still valid, .strict() rejects unknown keys (repo_path, branch, base_ref, hook content) and success-only fields on the failure event, and wrong types, negatives, fractions and out-of-vocabulary enum values are rejected.

• Step-timer tests: the failing step is named, the outermost step that rethrew wins, a parallel step that finishes later doesn't hide the one that failed, a wrapped error is traced through cause (with a cycle bound), and finishing the timer stops the concurrency count.

• Concurrency tests: peaks of other creates and of spare work, the used spare left out wherever its peak fell, and work that starts after the create ends is ignored.

• Spare tests: a miss's base check is timed as the claim, not as the checkout; a failed hand-over's clean-up gets its own step; reset, origin (including rearm_then_prefetch), build time and idle time on hits, with a controlled clock; a building spare counts against other creates but not the one that used it.

• File-check tests on a temp dir: hook present, non-executable, sample-only, core.hooksPath, .git as a file, missing repo; index entry count from version 2 and 4 headers; no count for a missing, truncated, foreign, split or sparse index.

• App create handler tests through the existing worktree IPC harness: the event is sent after the create returns with no further Git call, exactly one event per create, the hook check is skipped with telemetry off, \\wsl.localhost\... reports wsl, SSH reports ssh without a hook check, a failed add reports failed_phase: git_worktree_add with no error text, and a throwing track() still returns the create's result or error.

• Runtime create tests: one workspace_created with create_entry_point: runtime, one workspace_create_failed naming the failed step, nothing for folder workspaces or requests rejected before the create, the SSH create's timing hand-off (execution_host: ssh and its steps), the create's own replacement spare not counted, a throwing track() doesn't change the create's outcome, and a source scan showing the two create paths only send through the shared sender and never call each other.

• Ran 90 related files (worktree IPC, runtime create, spare pool, telemetry, instrumentation, orca-runtime.test.ts): 2248 passed, 1 skipped. Typecheck (tsconfig.node, tsconfig.tc.web, tsconfig.cli), oxlint, the changed-code quality gate and the anti-slop audit pass on the latest commit.

Agent skill upstream boundary

• Not applicable, or this change follows docs/reference/agent-skill-sharing-upstream-boundary.md and copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

Security: only numbers and fixed categories leave the machine, under the existing consent check. Cross-platform: the file check handles Windows (no execute bit) and WSL paths; nothing is read on SSH. Mobile and paired clients: no wire change they parse. Performance: nothing new on the create path before it returns; the file check is after, capped at 2 s, and skipped with telemetry off.

Checklist

• This PR is small and focused
• I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
• Before/after screenshots or videos attached for UI changes, or N/A with reason
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
• pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)

[brennanb2025]

QA screenshots

Tested head a108d233461 in a hidden dev build on a separate Mac, with an isolated profile and home, against a small local test repo. The same failed-create steps were repeated on the base commit 02790c53e88 for comparison.

• Launch: PASS. The app started and the test repo was added.
• Successful create from the New Workspace dialog: PASS. The dialog closed, the new worktree appeared in the sidebar and opened, and its terminal started (about 4 s for the first create, 1 s for the second). No error toast and no new console errors.
• Failed create (a git hook refuses the branch): PASS. The "Couldn't create worktree" error, the sidebar row, and Retry/Dismiss look the same as on the base commit. Only the branch name differs.
• Name with .. (bad..name): PASS. This build and the base commit behave the same: nothing blocks it before submit, and the create succeeds with branch bad.name.
• The create event's new timing fields: BLOCKED. Dev builds never send these events and there is no local-only way to capture them, so the field contents are covered by the unit tests only.
• Teardown: PASS. The app, its terminal daemon, and its pane processes were all stopped. Nothing was left running.

Launch, test repo added

New Workspace dialog filled in (qa-ok-1, base main, Blank Terminal)

After create: dialog closed, qa-ok-1 active in the sidebar, terminal started

Terminal works in the new worktree

Second create (qa-ok-2)

Failed create on this PR (qa-fail-1)

Same failed create on the base commit (qa-fail-2)

[brennanb2025]

Review status: ready (head 0d197f5bcfc)

The problem. Creating a worktree sometimes took minutes instead of seconds (2026-09-28). A lab study on one machine couldn't tell whether the prepared "spare" checkout helps or hurts real users. So we need to see, across real repos and machines, how long creates take, where the time goes, and what the spare did, before deciding #23699 (parked until this data exists).

What changes for users: nothing. The create works exactly as before, and nothing new is awaited before the worktree appears. The existing workspace_created / workspace_create_failed events gain optional numbers and fixed categories only: no paths, names, branches or error text. Consent and opt-out are unchanged, because the same track() call applies them.

Fixed during review

• The post-checkout hook check (a file-existence check after the create returns) used to run even with usage data sharing turned off. It now runs only when the event can be sent.
• execution_host reported local for a repo on a \\wsl.localhost\... path when the project used the default runtime, even though Git runs inside WSL there. It now uses the same path/WSL-distro rule Git routing uses.
• failed_phase is now read from the error itself: the outermost timed step the error passed through, following cause. The old step-ordering logic could report untimed when two steps ran in parallel.
• The SSH "older relay" authorization error now keeps the original error as its cause, so it still reports git_worktree_add. The message users see is unchanged, and a test pins this.
• The public privacy page also mentions the reason code when the prepared checkout isn't reused, and the step a failed create stopped in.
• The PR description now says correctly which creates send the event. In-app automation runs, work-item launches and session forks go through the same handler and send it. The CLI, mobile, paired web, headless automations, agent-launch and orchestration use the runtime path, which never sent it.
• CI: a test typing error and the symbol-naming rule (schema constants renamed to *Properties).

Deferred (minor, no user impact)

• On a WSL repo, a non-executable post-checkout hook still reads present, because the file check runs on the Windows side.
• A mobile code comment cites line numbers in create-types.ts that this PR moved.
• The hook-check values are defined in two places.
• The schema tests for the failed event don't cover unknown keys, negative or fractional numbers, or a bad execution_host.
• The parallel-step test covers a sibling step that succeeds, not one that fails.
• [core] hooksPath = x written on one line isn't detected (rare).
• Concurrency counts don't cover SSH provisioned-root adopts. Those send the events without the new fields, by design, since they are a registration rather than a timed create.
• The main-process log for a failed create may now also print the inner relay error's stack (log only, unverified).

Verified

• Two independent review rounds, with no P0–P2 findings left. The readiness checklist passed with no P0/P1/P2 candidates.
• 56 related test files: 1944 tests passed, 1 skipped. Typecheck passes for the node, web and CLI projects. oxlint, the quality gate and the anti-slop audit are clean. CI is green on 0d197f5bcfc.
• Electron QA on a remote Mac at a108d233461, compared with the base commit (screenshots in the QA comment above). The create succeeds, the failed-create error is unchanged, and there are no new console errors. The later commits change only tests and constant names.

Not verified

• The event payload in a running app. Development builds never send events and there is no local-only sink, so field contents rest on unit tests.
• A real Windows machine with a \\wsl.localhost repo: the tests simulate the platform.
• Real event delivery. By design, no events were sent during review.

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Adds telemetry fields to workspace creation events.

The PR appears safe to merge, with non-blocking inaccuracies in the repository context and previously noted event measurements.

Findings

1.  Inactive worktree config affects telemetry ▶
2.  Success event can be lost ▶
3.  Execution host can be mislabeled ▶
4.  WSL hooks can be misclassified ▶
5.  Hooks path ignores config sections ▶

Summary

The PR adds step timings, prepared-checkout outcomes, concurrency and coarse repository context to workspace-create events, including runtime creates. It also adds a post-create repository probe. The probe needs to respect Git’s activation of per-worktree configuration before using that file to classify hooks or file counts.

_{Reviews (4) · Last reviewed commit: "fix(worktree): leave out the file count ..."}

[greptile-apps]

Success event can be lost If a local or WSL create finishes just before the app quits, workspace_created waits for the hook probe, which can take up to two seconds. If telemetry shutdown starts during that wait, track() drops the event. Previously the event was queued immediately, so this can leave a completed create out of the measurements.

[greptile-apps]

Execution host can be mislabeled For a Windows-side linked worktree in a WSL-configured project, Git can run on the Windows host. This code still records wsl because the project has a WSL distro, putting that create in the wrong host group for timing comparisons.

[greptile-apps]

WSL hooks can be misclassified When a WSL repository is accessed from Windows, this check uses the host's win32 platform and marks any post-checkout file as present. Git running inside WSL can skip a non-executable hook, so the event can incorrectly report that the repo has an active hook.

[greptile-apps]

Hooks path ignores config sections This search matches hooksPath anywhere in the config, including sections other than [core]. In that case, the probe reports custom_hooks_path even though Git uses the repo's default hooks directory, making the recorded hook context inaccurate.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 0f19ce71-de15-48bd-9a5e-bc4e20755d5f

📥 Commits

Reviewing files that changed from the base of the PR and between 3667459 and 2660cee.

📒 Files selected for processing (14)

• src/main/git/create-event-repo-probe.test.ts
• src/main/git/create-event-repo-probe.ts
• src/main/git/worktree-create-preparation.ts
• src/main/ipc/worktree-remote.ts
• src/main/workspace-create-event-fields.test.ts
• src/main/workspace-create-event-fields.ts
• src/main/workspace-create-telemetry.ts
• src/main/worktree-create-preparation-activity.test.ts
• src/main/worktree-create-preparation-activity.ts
• src/main/worktree-create-preparation-claim-registry.ts
• src/main/worktree-create-preparation-pool.ts
• src/main/worktree-create-preparation.test.ts
• src/main/worktree-create-preparation.ts
• src/main/worktree-preparation-discard-retry.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Walkthrough

Workspace creation now records phase durations, failure phases, prepared-checkout outcomes, execution host, worktree counts, and concurrent create and preparation counts. App and runtime creation flows pass timing data into local and remote operations. Telemetry schemas and event builders include available values, with repository hook and index facts probed for eligible creates. Added tests cover timing, concurrency, preparation outcomes, repository probing, event fields, and schema validation.

Priority: ⬇️ Low

Merge Risk: ⚪ Minimal · up to 2660c

This change adds measurement fields to workspace-create telemetry and should not change how workspaces are created. No blocking issues were found. Real event delivery has not been verified in a packaged build, so check it after release.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 2660c

The additional data is constrained to timings, counts, coarse buckets, and fixed categories. Transmission still checks the current telemetry preference, and the reviewed checkout flows retain ownership safeguards. No material security regression was established, but incomplete coverage prevents a stronger assurance.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• observed — The reviewed exposure is repository metadata collection in the creating process and additional properties in its existing install-identified telemetry stream. The runtime SSH path forwards the recorder to a creation function that marks execution as SSH, excluding that path from the local repository probe.

Trust Boundaries and Controls

• observed — Repository-derived facts pass through fixed-field construction and strict schema validation. The capture sink also enforces build, shutdown, initialization, burst-rate, and live-consent gates; raw repository paths and configuration contents are not added to these event properties.
• observed — Consent is checked before starting repository collection and again before transmission, but collection is not canceled when consent changes during an asynchronous read. The final gate prevents capture while consent is disabled; it does not reverse an already-started local read.

Resilience and Maintainability Implications

• observed — The preparation refactoring retains identity-bearing claims, idempotent release, and finally-based rearm in app and runtime callers. The new reset indicator is removed before returning the existing worktree result, keeping telemetry observation separate from checkout authority.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 26.32% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 95 functions across 43 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the main change: adding worktree creation timing and prepared-checkout outcome data to workspace creation events.
Description check	✅ Passed	The description follows the repository template and provides complete ELI5, change, rationale, issue, visual proof, testing, compatibility, security, performance, and checklist information. It also do…

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pullfrog]

✅ No new issues found.

Reviewed changes

• Event fields — workspace_created and workspace_create_failed gain optional timing, spare-outcome, and coarse-context fields, all numbers or closed enums (no path/branch/ref/error text). Additive optional fields keep old payloads valid; the public privacy page is updated to match.
• Timing recorder — the create handler now owns the recorder and threads it into the local/remote creates, so a failed create can still report failed_phase (matched by error identity, following cause, outermost rethrow wins) plus execution_host and elapsed time.
• Concurrency counter — new worktree-create-concurrency.ts tracks in-flight creates across the dialog handler and runtime local/remote paths for concurrent_creates, with no double counting.
• Post-checkout hook probe — new read-only probe reports hook presence without spawning Git, run fire-and-forget after the create returns and only when telemetry is on for local/WSL.
• WSL host labeling — wslDistroForCommand is exported and reused so execution_host follows the same rule Git routing uses.
• Tests — schema (strict rejection, backward compat, enum/type bounds), recorder (failed_phase incl. cause chains and cycles), field builders, hook probe on temp dirs, and handler integration through the worktree IPC harness.

I read the full diff and ran the new tests (66 passed) plus related existing suites (create-flow, sparse-checkout, execution-host routing, Windows, preparation, instrumentation, telemetry events, event classification) — all green. track() is non-throwing, so the fire-and-forget call is safe, and the validator delegates to the schemas, so there is no parallel allowlist to update.

Two non-blocking observations, no action expected:

• probePostCheckoutHookPresence is called without an explicit platform in production, so WSL repos are probed with Windows exec-bit semantics. The PR frames the field as best-effort and Windows stat likely cannot expose Linux exec bits anyway.
• workspace_created now emits after an async probe (capped at 2s), so a create immediately followed by app quit can lose the event to the shuttingDown gate. A deliberate latency-over-completeness tradeoff.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[greptile-apps]

Comments Outside Diff

These findings could not be posted inline.

•  Runtime steps remain unattributed src/main/runtime/orca-runtime-create-managed-worktree.ts:202 ▶

  For a runtime create, the recorder includes time spent preparing setup here and starting terminals later, but neither operation records its named timing phase. Both costs land in unattributed_ms, making slow runtime creates harder to compare with app creates.

  Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[pullfrog]

ℹ️ No critical issues — minor suggestions inline.

Reviewed changes

This run reviewed the newest commit (66c2f43), which reworks telemetry ownership and widens coverage well beyond the previous revision:

• Single shared sender — workspace-create-telemetry.ts now owns the create events for both entry points. A settled latch guarantees at most one workspace_created/workspace_create_failed per create, and a new create_entry_point field tags whether the Orca window (app) or the runtime API (runtime) ran it.
• Runtime creates now emit events — trackRuntimeWorkspaceCreate settles the event before the caller fires its re-arm, so CLI, agent, phone, paired-client and orchestration creates send the same fields the dialog does. Folder workspaces and requests rejected before the route resolves still send nothing.
• Spare-checkout reporting reshaped — prepared_checkout_reset (none/base_moved/retargeted) and prepared_checkout_origin (prefetch/rearm) replace the retargeted boolean; new prepared_checkout_claim/prepared_checkout_discard phases isolate the claim's probes and a failed finalize's cleanup from the plain add; the failure event now carries the spare outcome and prepared_checkout_wait_ms.
• New context fields — concurrent_preparations (peak other prepared-checkout builds/discards, excluding the one the create adopted) and repo_index_size_bucket (size only). The concurrency store now tracks preparation work in addition to creates, and the recorder threads through the runtime local/remote create paths.
• Probe consolidated — post-checkout-hook-presence.ts becomes create-event-repo-probe.ts and also stats .git/index; it still runs fire-and-forget after the create returns, only for local/WSL with telemetry on.

I read the full PR diff end-to-end plus the latest-commit delta. Two focused subagent passes on event exactly-once accounting and on the concurrent_preparations peak-exclusion/leak invariants returned no counterexamples — the settle latch holds one event per create, end() is memoized, and every tracked preparation work unit is ended.

ℹ️ The PR description predates the runtime-create change

The body still states that creates over the runtime API "have never sent workspace_created, and still don't," lists prepared_checkout_retargeted, and enumerates only the original 14 steps. The latest commit makes runtime creates send the event and replaces/extends those fields, so the description now contradicts the code it introduces and omits create_entry_point, concurrent_preparations, repo_index_size_bucket, prepared_checkout_claim_ms, prepared_checkout_discard_ms, and the failure event's spare fields.

Technical details

# PR description is stale for the runtime-create change

## Affected sites
- `docs/site/content/docs/telemetry.mdx` is updated, but the PR body's "What is recorded where" bullet still reads "Creates over the runtime API ... have never sent `workspace_created`, and still don't."
- The success bullet lists `prepared_checkout_retargeted` and the original 14-step set, missing `create_entry_point`, `prepared_checkout_reset`, `prepared_checkout_origin`, `concurrent_preparations`, `repo_index_size_bucket`, `prepared_checkout_claim_ms`, `prepared_checkout_discard_ms`.
- The failure bullet omits the added spare outcome and `prepared_checkout_wait_ms`.

## Required outcome
- The PR body describes the behavior this commit actually ships, since it is the primary artifact reviewers read and is what remains in the merge history.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

This counts the retry-path discard as preparation work, but stale-preparation cleanup reclaims trees through discardPreparedWorktree directly (worktree-create-preparation-stale-cleanup.ts:62), so those background removals never enter concurrent_preparations.

Technical details

# Stale-cleanup discards bypass the preparation-work count

## Affected sites
- `src/main/worktree-preparation-discard-retry.ts:61` — retry-path discard is wrapped; `startStalePreparationCleanup` runs `discardNextStalePreparation` in the background and calls the same `discardPreparedWorktree` without the wrapper.
- The reclamation runs after `startStalePreparationCleanup` awaits only `scanned` (not `cleanup`), so it can continue after the owning build's `work.end()` and is invisible to the metric.

## Required outcome
- `concurrent_preparations` reflects the disk work the field documents ("prepared-checkout builds and discards running at once during this create"), or the scope is made explicit.

## Open questions for the human
- Is the stale-cleanup path intentionally excluded, or should it go through `trackPreparationWork` too?

[pullfrog]

✅ No new issues found in the latest commit.

Reviewed changes

This run reviewed the delta since the prior pullfrog review (66c2f43 → 6d37872), which sharpens prepared-checkout telemetry and the repo probe.

• Index entry count — the repo probe now reads the tracked-file count from the 12-byte .git/index header (DIRC, version, big-endian count) instead of the index's byte size, and leaves it out for split or sparse indexes; repo_index_size_bucket becomes repo_file_count_bucket with file-count thresholds.
• Prepared-checkout build and idle time — a hit reports prepared_checkout_build_ms (arm to ready) and prepared_checkout_idle_ms (ready to claim, 0 when the create waited), from a readyAt stamp on the pool entry.
• rearm_then_prefetch origin — an automatic re-arm that the dialog's prefetch then asks for is distinguished from a pure re-arm.
• Event-send hardening — a shared settleOnce catches a throw from track() (sync and async), so bookkeeping can never change the create's result or mask its error.

One prior thread remains open and is untouched by this commit, so this review is not an approval.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[greptile-apps]

Inactive worktree config affects telemetry When .git/config.worktree exists but extensions.worktreeConfig is not enabled, Git ignores that file, but this probe still uses its settings. A stale hooksPath can make the event report custom_hooks_path for a hook Git does not use, and a stale sparse setting can omit a valid repo_file_count_bucket. This makes the repository context less reliable for create-time comparisons.

[pullfrog]

✅ No new issues found.

Reviewed changes

This run reviewed the delta since the prior pullfrog review (6d37872 → 3667459), which tightens the repo probe and moves spare-build timing onto a monotonic clock.

• Sparse-checkout detection widened — the probe now also reads .git/config.worktree and folds it into the config it inspects, and SPARSE_CHECKOUT_ON recognizes index.sparse / core.sparseCheckout set to any truthy value or written bare (only false/no/off/0 count as off). The tracked-file count is omitted under any sparse checkout, which is the conservative direction.
• config.worktree hooks path — a core.hooksPath set per-worktree now reports custom_hooks_path instead of absent, since the hook probe reads the combined config.
• Spare-build timing on the monotonic clock — buildStartedAt, readyAt, and claimedAt now use performance.now() (the same clock as the create's step timer) instead of Date.now(), so prepared_checkout_build_ms / prepared_checkout_idle_ms cannot be skewed by a wall-clock adjustment. createdAt stays Date.now() for TTL/eviction.
• Tests — new cases cover the config.worktree sparse variants, explicit-off keeping the count, a config.worktree hooks path, and the build/idle tests now mock performance.now().

The one prior pullfrog thread — concurrent_preparations misses the stale-preparation cleanup that reclaims trees via discardPreparedWorktree directly (worktree-create-preparation-stale-cleanup.ts:62) — is untouched by this commit, so this review is not an approval. No new inline comments.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[brennanb2025]

QA screenshots (v2, head 3667459)

Tested head 366745988250 in a hidden dev build on a separate Mac, with an isolated profile and home, against a small local test repo. The failed-create, ..-name and command-line steps were repeated on the base commit 02790c53e88 for comparison. Every create used the "Blank Terminal" agent.

• Launch: PASS. The app started and the test repo was added.
• Create from the New Workspace dialog: PASS. The dialog closed, the new worktree appeared in the sidebar and opened, and its terminal worked (qa-ok-1 showed up within about 1 s, qa-ok-2 in about 5 s). No error toast and no console errors.
• Spare checkout reuse and quick repeated creates: PASS. With the dialog left open for 15 s first, qa-spare-1 was created normally. Then qa-burst-1 to qa-burst-4 were created back to back. Each one opened with a working terminal, sat on the right commit with a clean status, and was listed by git worktree list.
• Failed create (a git hook refuses the branch): PASS. The "Couldn't create worktree" message, the sidebar error row, and Retry/Dismiss are the same as on the base commit. Only the branch name differs.
• Name with .. (bad..name): PASS. This build and the base commit behave the same: nothing blocks it before submit, and the create succeeds with branch bad.name.
• Create from the orca command line (the runtime path this PR changed): PASS. The CLI was built from each commit without installing anything and pointed only at the test app. A good name succeeded, printing the new worktree as JSON with exit code 0, and the worktree appeared in the sidebar. A hook-refused name failed with the same runtime_error message and exit code 1 on both commits, and the app showed nothing extra.
• The create event's new timing fields: BLOCKED. Dev builds never send these events and there is no local-only way to capture them, so the field contents are covered by the unit tests only.
• Teardown: PASS. Every test app, its terminal daemon and its pane processes were stopped, and the test ports were free afterwards.

Launch, test repo added

New Workspace dialog filled in (qa-ok-1, base main, Blank Terminal)

After create: qa-ok-1 active in the sidebar, terminal started

Terminal works in the new worktree

Second create (qa-ok-2)

Dialog left open for 15 s, then qa-spare-1 (Blank Terminal)

After qa-spare-1 and qa-burst-1

After back-to-back qa-burst-2, 3 and 4 (fresh profile; earlier worktrees are listed as discovered)

Failed create on this PR (qa-fail-1)

Same failed create on the base commit (qa-fail-2)

bad..name on this PR

bad..name on the base commit (branch bad.name-2 only because bad.name already existed)

Two command-line creates on this PR in the sidebar (both succeed: the test hook refuses only names containing qa-fail, which qa-cli-fail-1 does not)

The same two command-line creates on the base commit

After a hook-refused command-line create on this PR: no error row (the base commit looks the same)

[brennanb2025]

Review status: ready (head 3667459)

The problem. On 2026-09-28, creating a worktree sometimes took minutes instead of seconds. Part of that time went to waiting on the "spare" checkout Orca prepares in advance. A study on one machine couldn't settle whether the spare helps or hurts real users on balance, because the answer depends on repo size, disk, platform and what else is running. #23699 (remove the spare, or keep it under tighter limits) is parked until real numbers exist. This PR collects them.

What changes for users: nothing. Creates behave exactly as before. Nothing new is waited on before the worktree appears, and no new Git process runs. The existing workspace_created / workspace_create_failed events gain optional numbers and fixed categories only: no paths, names, branches or error text. Consent and opt-out are unchanged.

What changed in this review round. The earlier version only covered creates from the Orca window, and couldn't show whether spare work slows other creates. Fixed:

• Creates from the CLI, phone app, agents, paired clients and orchestration now send the same fields, marked create_entry_point: runtime. They use the spare too and are where creates come in bursts. workspace_created counts rise from this release; filtering to create_entry_point missing or app reproduces the earlier series.
• concurrent_preparations: how much spare-checkout work (builds and clean-ups) was running during each create, not counting the spare it used.
• On a miss, the spare's own checks and clean-up are timed as separate steps, so the plain checkout time is no longer mixed with them.
• On a reused spare: where it came from (prefetch, rearm, or rearm_then_prefetch), what reset it needed (none, base_moved, retargeted), how long it took to build and how long it sat ready.
• A failed create also reports what the spare did before it failed.
• repo_file_count_bucket: the tracked-file count from the index file's 12-byte header. It is read only after the create returns, with usage data sharing on, for local and WSL repos, within a 2 s cap. It is left out for split indexes and sparse checkouts.
• If sending the event fails, the create's own result or error is returned unchanged.
• The description now has a "What this will tell us" section and notes for reading the numbers.

Deferred (data limits, no user impact)

• none_armed doesn't yet say why no spare was ready (expired, failed before use, taken by another create), and spares that are built but never used aren't counted.
• concurrent_preparations doesn't split the automatic replacement spare from other spare work.
• No count of agents working during a create (needs new wiring).
• SSH creates time fewer steps, and SSH and local creates count toward each other's concurrent_creates.
• The hook check looks only at post-checkout, not the other two hooks fix(worktree): a create does one fetch and one checkout, and background work waits for it #23699 considers.
• Very large agent bursts can lose their last events to the existing rate cap (30 per event name, refilling 0.5/s).

Verified

• Fresh review rounds, each checking its own area: whether the data can answer the question (with the actual queries written out), the runtime create path (one event per create, no double sends), the spare-checkout counters and steps (the moved claim code is identical line by line; two creates racing for one spare still get exactly one hit), and a narrow check of each fix batch. No P0–P2 findings are left.
• The readiness checklist passed with no P0/P1/P2 candidates. 96 related test files: 2286 tests passed, 1 skipped. The node, web and CLI typechecks, oxlint, the quality gate and the anti-slop audit are clean. CI is green on 3667459.
• Electron QA on a remote Mac at 3667459, compared with the base commit (screenshots in the QA comment above). Dialog creates, a spare reuse and back-to-back creates, CLI creates (success and a hook refusal), and failed creates all behave the same as on the base commit, with no new console errors.

Not verified

• The event payload in a running app: development builds never send events, so field contents rest on unit tests.
• A real Windows or WSL machine.
• Real event delivery: no events were sent during review.

[pullfrog]

ℹ️ No new issues found in the latest commit — one minor test nit below.

Reviewed changes

This run reviewed the delta since the prior pullfrog review (3667459 → 6e90bda), which corrects how the spare is timed and how worktrees are counted.

• Worktree count by lock reason — the repo probe now reads each .git/worktrees/<entry>/locked file and drops entries whose reason carries Orca's preparation prefix, replacing the in-process countRegisteredPreparations subtraction. This excludes this process's spare, another process's spare, and a crash leftover the same way; a 1.5 s inner timeout keeps a slow per-worktree read from costing the other repo facts.
• First-build spare timing — prepared_checkout_build_ms is now the first build's arm-to-ready duration, so a later tip refresh no longer restarts it, while prepared_checkout_idle_ms still runs from the latest ready (build or refresh) to the claim.
• Tests — the probe test covers this process's, another process's, and a crashed spare plus a missing admin dir; the activity and tip-refresh tests pin the first-build and refreshed-idle numbers.

I read the incremental and full diffs and ran the four affected suites (47 passed). The worktree exclusion reuses the same parseWorktreePreparationOwnerPid predicate the worktree listing uses, so the two agree; the timing change matches the field comments and the PR body. The one open prior thread is untouched by this commit, so this is not an approval.

ℹ️ Nitpicks

• src/main/git/create-event-repo-probe.test.ts:82 — the case named "does not count a spare whose admin directory Git has not written yet" registers no spare: it only adds feature-a, so it passes under any implementation, including one that never subtracts an unregistered spare. Either create an in-memory spare for the repo or drop the case; the actual exclusion is already covered by the preceding test.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}