[kyle-sexton]

No related issue: moves the pr-verify lane onto ci-workflows' run-claude-cli launcher, the next lane of the lane-funding rollout after intake

Hold: a human merges this.

Summary

pr-verify's judgment now runs on run-claude-cli (ci-workflows v0.52.0) as the automations role instead of claude-code-action, so it spends AUTOMATIONS_CLAUDE_API_KEY credits first and falls back to AUTOMATIONS_CLAUDE_CODE_OAUTH_TOKEN only on a credit stop. Lane merges require this verdict (require-verifier-verdict: true), so the exact job was proven in the sandbox before this PR.

Fix

• pr-verify.yml: managed settings before runner isolation; the model's data moves to pr-verify-data in the workspace, since --restricted confines file tools to the working directory, with Read(./pr-verify-data/**) allowed and .base, Glob, Grep and every other tool denied. Verifier preamble, leg 10 min inside a 22 min step inside the job's 30, background tasks off, report-lane-outcome after the judge, and a final step that fails the job when no verdict was written.
• write-verdict.mjs reads structured_output from the launcher's execution file, and writes no verdict when the result carries a permission denial or key-shaped text.
• resolve-config gains model and effort outputs (empty for a default model or an unset effort); claude-args and settings-json are unchanged for other callers.
• Funding docs, the Verifier verdict and Models paragraphs, a changelog fragment, and two comments that pointed at pr-verify.yml's old wiring.

Revert plan: if the first run on main fails, revert the merge commit in a PR. After a fix, re-run pr-require-checks on lane PRs whose head was judged in the broken window, since a head with no verdict is not re-judged until pr-require-checks runs again.

Verification

• Sandbox probe of the same steps at this branch's SHA: run 39260940993 green. Clean case: leg 1 on AUTOMATIONS_CLAUDE_API_KEY, verdict written. Canary case: the model's Read of .base denied, the canary absent from the output, and the verdict refused for the denial.
• node --test .github/scripts/pr-verify/*.test.mjs .github/actions/resolve-config/*.test.mjs: 388 pass, 0 fail.
• Runner policy, actionlint, zizmor and scripts/check-affected.sh --tests pass.

Related

• feat(run-claude-cli): make effort optional ci-workflows#786 (effort optional, released as v0.52.0)
• feat(intake): fund the intake lane from the automations role on run-claude-cli #8375 (intake on run-claude-cli, the pattern this follows)
• test(pr-verify): probe pr-verify's judgment on run-claude-cli pr-pipeline-sandbox#171 (probe, closed unmerged)

🤖 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-19T13:43:51.738264Z	7256b48	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-security-review reviewed 7256b485c34f38658965b747c31cb6f40191ad70: 0 finding(s), 0 as inline comments.

No security findings in PR #8424 at head 7256b48. I read the full diff, including pr-verify.yml, write-verdict.mjs, the prompt, and the resolve-config changes.

• Model access: The model has tools: Read and allowed-tools: Read(./pr-verify-data/**) under dontAsk. Everything else is denied: ./.base, Glob, Grep, Bash, Edit, Write, WebFetch, Agent and mcp__*. The workspace root holds only .base and pr-verify-data, since the PR's code is never checked out. No project .claude settings or CLAUDE.md can load from the working directory, which makes up for dropping --setting-sources user. The credentials go to the launcher, not the model.
• Trigger and checkout: The trigger is still workflow_run from main, behind the trusted-actor gate, and permissions is read-only. .base is still checked out with persist-credentials: false. The managed-settings step runs before runner isolation, and all new actions are pinned by SHA.
• Verdict file: write-verdict.mjs reads the execution file and log from step outputs, not from model text. It fails closed on an unreadable file, a missing result, a malformed line in the run log, or any permission denial on any leg. The key-shape check reuses the SECRET_PATTERNS regex, which has no g flag, so .test() carries no state between calls. The error messages print only tool names, never a call's input.
• Failure handling: The Fail without a verdict step makes a missing verdict fail the job. Model text still goes through the schema check and length caps before it is uploaded.
• Not a finding: The credential check covers only Anthropic key shapes, and a deliberately obfuscated key could slip past it. The model never receives the credentials, so I treated this as hardening, not an exploitable path in this diff.
• Instruction surfaces: No guardrail is deleted or softened. The prompt.md change adds a rule that a denied read voids the verdict. I did not need the instruction exception register for this diff.

[github-actions]

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

Code review: PR #8424 (pr-verify on run-claude-cli)

I found nothing to block or flag, so I posted no inline comments.

I read the full diff, the PR context and the unchanged parts of write-verdict.mjs and pr-verify.yml that the changes touch. I ran no tests or workflows. The PR's test counts and the sandbox probe run (39260940993) are author-claimed and unverified by me. The PR has no closing issue ("No related issue: …"), so there were no acceptance criteria to check.

What I checked:

• Credential scan. ANTHROPIC_KEY comes from SECRET_PATTERNS in lib/publish-gate.mjs:28. It is a non-global regex, so repeated .test() calls carry no state. .base is a full checkout, so the new import of lib/publish-gate.mjs resolves.
• Output handling. buildVerdict already accepts either a string or an object, so passing the parsed structured_output object from the execution file works.
• Denial handling. A permission denial in the last leg (structuredOutput) or in any earlier leg (earlierDenials, read from the log) stops the verdict. Both fail closed. Only tool names are printed, never a call's input.
• Workflow ordering. Managed settings are applied before runner isolation, and the data directory is now in the workspace. Judge, outcome report, verdict, upload and the new "Fail without a verdict" step are ordered correctly. A skipped or failed verdict step fails the job, as intended. The 10-minute legs fit in the 22-minute step and the 30-minute job.
• Model and effort. A default model resolves to an empty value. The prompt step fails on it, and a test covers that case.
• Docs. The resolve-config README and action.yml, the pr-pipeline YAML and README, and the changelog fragment match the code. The two comments that pointed at pr-verify.yml's old wiring are updated.

Minor, below the reporting bar:

• write-verdict.mjs has export const artifactName =(verdict) =>, a missing space the formatter will catch.
• earlierDenials calls JSON.parse on every non-empty log line. A non-JSON line would throw and refuse the verdict. That is fail-closed, and I did not see the log format, so I could not tell whether it is ever hit.