[kyle-sexton]

No related issue: registers the ci-workflows v0.62.0 contracts so claude-code-plugins can repin to it.

Summary

Registers the ci-workflows v0.62.0 tag (2fe38c031867900824c164e33a140a335ed9ecf0) contracts for intake-triage.yml, pr-review.yml and pr-review-security.yml, in the same shape as #843 (v0.61.0) and #842 (v0.60.0). v0.62.0 adds only ci-workflows#858, which bounds the subprocess isolation install that timed out in two hosted security-review runs on claude-code-plugins.

Fix

• components/runner-policy/policy.json: three entries keyed @2fe38c03…, verbatim copies of the @164c2809… (v0.61.0) entries, each placed right after its v0.61.0 entry.
• components/runner-policy/README.md: a v0.62.0 rollout paragraph after the v0.61.0 one.
• components/runner-policy/runner-policy.test.mjs: REPINE_LANE_SHA_V0_62_0 and a test that the three v0.62.0 contracts equal their v0.61.0 entries and that exactly three v0.62.0 contracts exist.

Review basis

git diff 164c2809 2fe38c03 (ci-workflows compare API) touches four files: the three workflows and .github/scripts/claude-lane-install-isolation.test.cjs. No commit-relative action changes.

• For each workflow, yq comparison of .on (workflow_call inputs and secrets), .permissions, each job's permissions, runs-on and timeout-minutes, the job list, and every step's uses: identical between the two tags.
• The only hunks are the "Install subprocess isolation" step (pr-review.yml, pr-review-security.yml) and the two "Isolate the runner" steps (intake-triage.yml): apt is skipped when bwrap and socat are present, every apt-get call runs under sudo timeout against one shared deadline (50 s in the review lanes, 100 s in intake), and the final check requires both tools.

Verification

• npm run test:runner-policy: 335 tests, 335 pass, 0 fail, including ✔ the intake-triage and review contracts at the v0.62.0 tag copy their v0.61.0 entries forward verbatim.
• npm run lint:runner-policy: Runner policy passed.
• Against the claude-code-plugins repin worktree (three callers moved to @2fe38c03…): its vendored policy gives three runner-target-contract failures (auto-approval declined); this branch's runner-policy.mjs and policy.json give Runner policy passed.
• lefthook pre-commit (typos, editorconfig, markdownlint, gitleaks, biome): clean.
• Left out: nothing.

Related

• ci-workflows#858, released in v0.62.0.
• The claude-code-plugins repin PR passes its runner-policy gate once this merges and syncs.
• #844 (automated repin of the standards lane components to v0.61.0) is separate and not touched here.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-22T18:04:17.948062Z	f0f1ee7	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

claude-review reviewed f0f1ee7d46f04ac7efdb5e3e33d3cb0cdf736698: 0 finding(s), 0 as inline comments.

No findings. I reported nothing inline.

What I checked (read in the diff and the checkout at f0f1ee7):

• policy.json: The three new @2fe38c03… entries for intake-triage, pr-review and pr-review-security match the neighbouring @164c2809… (v0.61.0) entries. I compared routing, runner input, role, allowed inputs, allowed secrets and caller permissions by eye. Each new entry sits directly after its v0.61.0 entry, as the PR describes.
• runner-policy.test.mjs: The new test looks up each v0.61.0 entry and asserts the v0.62.0 entry deep-equals it. It also asserts that exactly three contracts end in the v0.62.0 SHA. The REPINE_LANE_SHA_V0_62_0 constant matches the SHA in policy.json.
• README.md: The v0.62.0 paragraph follows the v0.61.0 paragraph, in the same format as the earlier per-tag paragraphs. It names the right workflows and says no inputs, secrets, permissions or routing change, which matches the policy entries.
• PR body: The No related issue: <reason> opener and the Summary/Fix/Verification/Related sections follow .claude/rules/pr-body-contract.md. There is no closing issue, so there were no acceptance criteria to check.

Not verified:

• I did not run npm run test:runner-policy or lint:runner-policy, so the 335-pass and lint-clean results are author-claimed.
• I did not check the claims about the ci-workflows v0.62.0 diff, such as which four files changed and that action references are identical. The review environment gave me no access to that repository's tag or compare API. The policy entries themselves only restate the v0.61.0 interface, and the diff is consistent with that claim.
• There are no plugin manifests in this diff, so the manifest checks do not apply.

[github-actions]

claude-security-review reviewed f0f1ee7d46f04ac7efdb5e3e33d3cb0cdf736698: 0 finding(s), 0 as inline comments.

Security review: PR #846 (head f0f1ee7)

No security findings.

The PR changes three files: components/runner-policy/policy.json, its README, and runner-policy.test.mjs. It adds three approvedReusableWorkflowContracts entries for the ci-workflows v0.62.0 tag (2fe38c031867900824c164e33a140a335ed9ecf0): intake-triage, pr-review and pr-review-security.

• Verbatim copy. I compared each new entry with its v0.61.0 entry (164c2809…) by reading both. routing, runnerInput, role, allowedInputs, allowedSecrets and allowedCallerPermissions are identical for all three, so the allowlist does not widen. The new entries grant no extra inputs, secrets or caller permissions (for example id-token: write and pull-requests: write, which the v0.61.0 entries already carry).
• Pinned. Each new key is a full 40-character commit SHA, not a tag or branch, so the reference is immutable. I did not check that the SHA matches the ci-workflows v0.62.0 tag. The workflow body at that SHA is outside this PR's diff and I did not read it.
• Test. The new test asserts that each v0.62.0 entry deep-equals its v0.61.0 entry and that exactly three entries carry the new SHA. This guards against the entries drifting from the claimed verbatim copy.
• Instruction surface. Nothing in the diff deletes, narrows or softens a standing instruction. The README change is additive prose.
• Plugin manifests. No plugin.json or marketplace.json is touched, so there are no manifest <field> lines.
• Actions hardening. No workflow files are modified, and the zizmor lane covers that area.

I did not consult the instruction-exception register, because the diff removes no instruction.