Uh oh!
There was an error while loading. Please reload this page.
Fix worktree removal timing out on large install trees - #3902
Merged
t3dotgg merged 1 commit intoSep 4, 2026
Conversation
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Uh oh!
There was an error while loading. Please reload this page.
Contributor
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a focused bug fix that raises only the worktree-removal deadline from 15 seconds to a bounded five minutes, allowing large filesystem cleanups to complete without changing cleanup semantics. A targeted integration test covers the longer-running path. You can add or adjust custom eligibility rules. Learn more. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
jakeleventhalforce-pushed
the
t3code/fix-worktree-remove-timeout
branch
from
July 18, 2026 14:06
35a62d9 to
4ce5dfaCompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit cc622e2b79c62c23210db8ce83a97cace23eb853. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
jakeleventhalforce-pushed
the
t3code/fix-worktree-remove-timeout
branch
from
July 29, 2026 15:56
5e76b99 to
c04833bComparejakeleventhalforce-pushed
the
t3code/fix-worktree-remove-timeout
branch
3 times, most recently
from
August 10, 2026 20:12
0f5815f to
6e80eabCompare
This was referenced Aug 23, 2026
lastobelus pushed a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 24, 2026
Let Git perform forced worktree removal with a 30-minute deadline so large install trees can finish while stalled filesystems still return an actionable error. Adapted from pingdotgg/t3code PR pingdotgg#3902, pinned at 6e80eab9601f2cfec525d179cedeb6c8c6b31ced. Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 24, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 24, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
jakeleventhalforce-pushed
the
t3code/fix-worktree-remove-timeout
branch
from
August 26, 2026 02:35
6e80eab to
b457585Comparelastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 28, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 28, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 29, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 29, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 29, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 30, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Aug 31, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 1, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 1, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 1, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 1, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 1, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 1, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 1, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 1, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 2, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 2, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 2, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 2, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 2, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 2, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 3, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 3, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 3, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
lastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 3, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
jakeleventhalforce-pushed
the
t3code/fix-worktree-remove-timeout
branch
from
September 3, 2026 12:14
b457585 to
4410854Comparelastobelus added a commit
to lastobelus/lastCode
that referenced
this pull request
Sep 3, 2026
Large thread worktrees can take much longer than the existing 15-second `git worktree remove` deadline, producing a cleanup failure after Git has already started deleting the tree. This keeps Git as the sole owner of worktree deletion and gives it a 30-minute deadline. That is long enough for multi-gigabyte install trees while still returning an actionable error for a genuinely stalled filesystem. The integration test now exercises the forced-removal path. Upstream provenance: - Source: pingdotgg#3902 — “Fix worktree removal timing out on large install trees” by Jake Leventhal - Pinned upstream head: `6e80eab9601f2cfec525d179cedeb6c8c6b31ced` - Linked issue: pingdotgg#3593 - LastCode adaptation: replaced the upstream pre-deletion traversal with a bounded native Git removal after review exposed unavoidable pathname-swap races Validation on head `eea7b6f1501e174e45a1d993b2e03623a98a1fd0`: - Focused forced-worktree-removal integration test passed - Server typecheck passed (pre-existing Effect suggestions only) - Quick local CI passed - Full local CI passed with an exact-head stamp - Automated review has zero current unresolved findings No client, provider, contract, connection-mode, or documentation behavior changes; this is the server-side removal primitive only. Implemented with GPT-5.6-sol through the Codex harness. Co-authored-by: Jake Leventhal <jakeleventhal@me.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Uh oh!
There was an error while loading. Please reload this page.
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Solves #3593
git worktree removea bounded five-minute cleanup window for dependency-heavy worktrees.main.Test plan
pnpm exec vp test run apps/server/src/vcs/GitVcsDriverCore.test.ts(58 passed)pnpm --filter t3 typecheckgit diff --checkUpdated with Codex (gpt-5.6-sol) in the Codex harness.
Note
Fix 'removeWorktree' timeout to 5 minutes for large install trees
Updates GitVcsDriverCore.ts to use a new 5-minute
WORKTREE_REMOVE_TIMEOUT_MSconstant instead of the default 15-second timeout forgit worktree remove. Adds an integration test in GitVcsDriverCore.test.ts that verifies the removal can run longer than the default command timeout without failing.Macroscope summarized 4410854.
Note
Medium Risk
Changes Git subprocess timeout for worktree teardown; longer waits on stuck removals but no auth or data-model impact.
Overview
Fixes premature failures when tearing down worktrees that contain large dependency trees (e.g.
node_modules), wheregit worktree removecan exceed the previous 15 second limit.removeWorktreenow uses a dedicatedWORKTREE_REMOVE_TIMEOUT_MS(five minutes), aligned with the existing generous timeout forworktree add. Comments note the change is meant to stay bounded while avoiding killing Git mid-cleanup on slow filesystems (especially Windows). Idempotent “already gone” handling is unchanged.Adds an integration test that wraps
git worktree removein a 31s delay and asserts removal still completes—mirroring the existing “push longer than default timeout” pattern.Reviewed by Cursor Bugbot for commit 4410854. Bugbot is set up for automated code reviews on this repo. Configure here.