centralize worktree setup in Node#1115
Merged
TheGreenCedar merged 2 commits intoJul 14, 2026
Merged
Conversation
5ffe2d8 to
35b89d3
Compare
35b89d3 to
c714420
Compare
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Context
The worktree bootstrap had three owners: a 594-line shell implementation, a 668-line PowerShell implementation, and a Node dispatcher. Ref parsing, CLI selection, builds, rehydrate, index refresh, and readiness behavior could drift by platform. The ref parser also treated every 40-character name as detached, including nonhex branch names.
Base: 2e9352b
Head: 5ffe2d8
What changed
The production setup surface drops by roughly 625 lines; the complete PR is net -337 lines including the centralized tests and CI wiring.
How to review
Start with scripts/codex-worktree-setup.mjs, especially remoteHeadName, findCli, resolveCli, and runSetup. The shell and PowerShell files should contain no setup decisions. Then review the shared test fixture and the proof-routing change.
Verification
Passed locally on macOS:
Cargo was intentionally not run because another lane owned the shared Cargo queue and this change is limited to Node, adapters, docs, and workflow routing. The PowerShell adapter cannot execute on this Mac; the promoted Windows x64 lane now runs the same suite and adapter smoke.
Risk
The main risk is process-launch behavior on Windows, especially native and .cmd CLI candidates. Selection and orchestration are covered with injected cross-platform fixtures; real PowerShell forwarding remains a Windows proof claim. Release asset install behavior keeps the existing platform installer boundary on Windows and the checksum-verified tar path on POSIX.
Closes #1109
Refs #899