fix(security): restack hourly gh subprocess isolation on latest main

[seonghobae]

Purpose

Harden the repository-owned hourly commercial-readiness GitHub CLI subprocess boundary on the current protected lineage without broadening workflow authority or changing the separate credential-source policy tracked by #111.

Test-first proof and RCA

Exact RED head e3f65a97416d9da529f4a1a5706134cd1bdaad7e added hostile-parent and delegated-token regressions. Application ci 31591145789 checked out that exact head and failed at the intended boundary because createGhSubprocessEnvironment and redactSensitiveValue were absent and the child invocation had no explicit reviewed environment.

The contract requires the shell-free gh child to receive only pinned GH_HOST=github.com, deterministic NO_COLOR=1, optional non-empty PATH, and explicit optional GH_TOKEN. It also requires exact delegated-token removal before startup/non-zero child diagnostics can become retained text.

A later current-line audit found that head 00cb236bbb4cd682728c8dc42f65274a33bfb187 had accidentally preserved the final regression blob while selecting predecessor source blob 2880ffde8d40ed179a9dcecd97a09b2def4ff4c5, which had the child-environment allowlist but still retained raw delegated-token diagnostics. That was a real source/test mismatch, not a merge-authority or infrastructure finding.

Current GREEN source

Current exact head b634b8349f1dd09314d6347dad695d6862a4e233 is a non-forced two-parent refresh over protected main 18cac8dcab31dd53048d5d14ad01673b5b77d141. It is zero commits behind current protected main and differs on exactly two paths:

• scripts/hourly-commercial-readiness.mjs blob bbde521f440626ef31ad00e81450bbb0ea57dcee;
• test/hourly-commercial-readiness-script.test.ts blob 9602dda192b14279590f662dbbd4d097b3c4d261.

The source now exports createGhSubprocessEnvironment and redactSensitiveValue, constructs one childEnvironment, passes it to spawnSync(..., { shell: false, env: childEnvironment }), and redacts the exact delegated GH_TOKEN from startup and non-zero diagnostics before bounding. The current regression blob requires those production semantics.

The five code-quality findings emitted while the deliberate RED exports were absent are resolved. Their predecessor COMMENTED review is diagnostic evidence only, not approval.

Exact current-head state

For exact head b634b8349f1dd09314d6347dad695d6862a4e233:

• application ci 31595865068: queued/non-passing at the latest fresh read;
• reviewer-ci 31595865046: queued/non-passing;
• protected-base eligible central Security Scan 31595865079: queued/non-passing;
• formal visible review: COMMENTED on a predecessor, not approval;
• all five existing inline review threads: resolved;
• GitHub reports mergeable, but queued exact-head evidence prohibits merge.

Keep Draft until the unchanged exact head has terminal-success application/reviewer/security evidence and current findings/reviews are freshly re-read. No predecessor, queued, model, status, synthetic or rate-limited evidence is promoted.

Authority boundary

This repair narrows one GitHub CLI child-process and retained-diagnostic boundary. It does not redefine parent credential acquisition (#111), provision Apps/reviewers, weaken live governance, publish a release, deploy production, choose an outbound license, establish KPI/revenue/transfer evidence, or make Noema acquisition-ready.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 40 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4a663fd5-7cc7-4b4a-9ab4-086fcbd21423

📥 Commits

Reviewing files that changed from the base of the PR and between 2674bde and a25f932.

📒 Files selected for processing (3)

• scripts/hourly-commercial-readiness.mjs
• test/hourly-commercial-readiness-credential-ingress.test.ts
• test/hourly-commercial-readiness-script.test.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}