[kyle-sexton]

Refs: #11386

Summary

The control-claude-code driver's note still called the OAuth token's apiKeySource UNVERIFIED. The owner's spike leg measured it as none, so the note now cites that record.

Fix

Comment-only change in driver/driver.mjs. CI_KEY_SOURCES already maps CLAUDE_CODE_OAUTH_TOKEN to none, which matches the measurement, so no code changes.

Verification

• Owner's run on Claude Code 2.1.316: apiKeySource: none, exit 0 (record).
• driver.test.sh ran and passed on an ubuntu-24.04 runner: test-bash (0) job, conclusion success, its plan lists the file.
• scripts/check-changelog-fragments.sh --check-required origin/main exits 0.
• Left out: a WSL 24.04 run, because this host has only Ubuntu 26.04 (wsl.exe --list); the status comment on the issue accepts that job's log instead.

Related

N/A

Remaining

• The first screen of the CLAUDE_CODE_OAUTH_TOKEN leg. It needs a token from claude setup-token, which agents do not create. The owner's run recorded apiKeySource and the exit code, not the screen. feat(harness-ops): let control-claude-code run unattended on sessions it launches #11386 closes once that screen is recorded.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VQb9Q1VgLEiwGgRVshK3b7

[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-11-03T04:55:53.950787Z	5b78814	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 5b788140a92249ef0ced4421287b84ba7b4cfb47: read 2 of 2 changed file(s); 0 finding(s), 0 as inline comments.

Security review: no security issues found

I read both changed files in full:

• .changes/harness-ops/docs-11386-oauth-leg-record-b4e1f073.md is a new changelog fragment with bump: none. It is text only.
• plugins/harness-ops/skills/control-claude-code/driver/driver.mjs changes only the comment block above CI_KEY_SOURCES. The note used to say the OAuth token's apiKeySource was UNVERIFIED. It now cites the owner's measurement (none, on Claude Code 2.1.316). No code changes. CI_KEY_SOURCES still maps CLAUDE_CODE_OAUTH_TOKEN to 'none' (driver.mjs#L36). That matches the PR description's claim. A token reporting any other source is still refused, and the comment still says so.

Other checks:

• Instructions: the comment drops the conditional "until the spike records it". The refusal it described is still in place. The edit loosens no rule and changes no behaviour.
• Trust controls: neither file matches a trusted-path glob. Nothing here touches a trust control or a merge hold.
• Plugin manifests: none changed.
• PR context: I found no embedded instructions in the PR text.
• Prior findings: none. The round cap was not reached.

critical-findings: 0

[github-actions]

claude-review reviewed 5b788140a92249ef0ced4421287b84ba7b4cfb47: read 2 of 2 changed file(s); 0 finding(s), 0 as inline comments.

Code review: PR #12707 (complete, 2 of 2 files read)

No findings.

This PR changes comments only:

• plugins/harness-ops/skills/control-claude-code/driver/driver.mjs (L108–117): The note above CI_KEY_SOURCES is updated. It no longer calls the CLAUDE_CODE_OAUTH_TOKEN apiKeySource UNVERIFIED. It now cites the owner's measurement on feat(harness-ops): let control-claude-code run unattended on sessions it launches #11386 (none, Claude Code 2.1.316). The note matches the code below it: CI_KEY_SOURCES maps CLAUDE_CODE_OAUTH_TOKEN to NO_KEY = 'none' (L118–119). The recheck trigger was updated to fit now that the value is measured. No code changed.
• .changes/harness-ops/docs-11386-oauth-leg-record-b4e1f073.md: bump: none is right for a change that touches only comments.

Closing issue: The PR only references #11386 (Refs:) and closes no issue, so there are no acceptance criteria to check. The PR body's "Remaining" section says the issue stays open until the token leg's first screen is recorded.

Verification: The test run and changelog-check results in the PR body are the author's claims and I did not check them. I had no shell in this run and ran nothing.

No plugin manifest changed. Neither file matches a trusted path. Prior findings: none (round 0 of a cap of 3).