fix(source-control): signal worktree-create lock failure with exit 5

[kyle-sexton]

Fixes #2389.

On git worktree lock failure the helper still prints the worktree path but now also emits lock_failed=1 on stderr and exits 5, so orchestrators can detect an unarmed liveness guard.

Related

• source-control: worktree-create arms the #2257 liveness lock best-effort — a lock failure warns to stderr, exits 0, and leaves the guard silently unarmed #2389 — worktree-create lock failure signal

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[claude]

Claude finished @kyle-sexton's task in 44s —— View job

---

Security Review

• Fetch PR diff (gh pr diff / git diff origin/main...HEAD)
• Read changed files
• Analyze for security issues
• Post findings

Scope: plugins/source-control/scripts/worktree-create.sh (+6/-0), plugins/source-control/.claude-plugin/plugin.json (version bump), plugins/source-control/CHANGELOG.md (docs).

Findings: none.

The functional change is narrow: on git worktree lock failure, the script now also prints lock_failed=1 to stderr and exits 5 instead of exiting 0 (worktree path is still printed to stdout beforehand). I reviewed this against the categories in scope for this lane (injection, authorization/trust-boundary gaps, unsafe secret/token handling, logic flaws with security consequence):

• No new input is consumed — lock_failed is an internal integer flag (0/1) set by the script itself, never derived from --name, --root, or any other caller-controlled value.
• All new printf calls use literal %s format strings with no interpolation of untrusted data, so there's no new injection surface (command, path, or format-string).
• The new exit path runs strictly after git worktree add has already succeeded and after the worktree path has been printed, so it doesn't change what gets created, where, or under what permissions — it only changes how a pre-existing lock-failure condition is signaled to the caller.
• The change is a net positive from a race/TOCTOU standpoint: previously a failed git worktree lock (the liveness guard that stops a concurrent cleanup sweep from deleting an in-use worktree, source-control:worktree cleanup classifies by cleanliness, not liveness — a clean worktree with a rebase in flight is removed without --force, and the 'locked' flag it honors is never armed #2257) was reported only as an easy-to-miss stderr warning with exit 0. Callers that didn't scrape stderr had no way to detect the unarmed guard. Signaling via a distinct exit code (5) and a machine-parseable lock_failed=1 marker makes that failure mode detectable instead of silently swallowed — it doesn't introduce a new authorization or trust-boundary gap.
• plugin.json/CHANGELOG.md changes are metadata/documentation only — no security relevance.

No CRITICAL/IMPORTANT/SUGGESTION items to report for this PR.

[github-actions]

Warning

Automated security review did not complete — this is an infrastructure failure, not a review verdict.

Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."

• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/31582926425
• Failure class: other
• Last SDK result: (no execution file was produced)

The check is green on purpose, and it is not evidence. It certifies that a security pass ran, and this one did not complete — but the cause is outside this PR's control, so merging is deliberately left unblocked rather than locking every merge for the length of the outage. Nothing was reviewed at this head. Where this check is required, it is satisfied without that evidence; a human should review security-sensitive changes here before merging.

Re-run the job to retry the review; a new push also retries it only if the caller's pull_request triggers include synchronize (the canonical security caller keeps it). An automatic retry may already have run — it is skipped when a partial review could duplicate comments, or when the failure class needs an operator.

Re-running does NOT help for every class:

• rate-limit that persists across re-runs, or auth — the credential or usage budget needs an operator; retrying will not clear it.
• a run that exhausted its turn budget ("subtype":"error_max_turns" above) will exhaust it again. As the PR author, split the change into smaller PRs; raising --max-turns is a change to the caller workflow, not something you can set on this PR.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b808f1f92e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Warning

Automated review did not complete — this is an infrastructure failure, not a review verdict.

Treat any Claude comment on this PR (including a placeholder like "I'll analyze this and get back to you") as incomplete, not "no findings."

• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/31582926215
• Failure class: other
• Last SDK result: (no execution file was produced)

Re-run the job to retry the review. A new push re-triggers this lane only if the caller's pull_request triggers include synchronize (the canonical caller omits it).
An automatic retry may already have run — it is skipped when a partial review could duplicate comments, or when the failure class needs an operator (auth).