Self-hosted CI is a bridge, not the target state — and it must not survive the public flip unmitigated

[KenTaniguchi-R]

State as of filing

macmini-agentcall is registered and online (labels self-hosted, macOS, ARM64), but no job targets it. Every workflow on main still declares a hosted runner, and ci.yml / invariants.yml are workflow_dispatch: only, so nothing fires on its own either.

Workflow	runs-on	Triggers
ci.yml:19 verify	ubuntu-latest	workflow_dispatch
ci.yml:75 packed-cli-consumer	${{ matrix.os }} — [macos-latest, ubuntu-latest]	workflow_dispatch
ci.yml:117 windows-compat	windows-2025	workflow_dispatch
invariants.yml:23	ubuntu-latest	workflow_dispatch
release.yml ×3	ubuntu-latest	release: published

Registering a runner is half the change. A runner with no job targeting it never picks up work.

The decision

Superseded 2026-08-28 — see "Blocking precondition on going public" below.
The runner-topology decision below (verify stays self-hosted for regular
CI) still stands; what changed is the public-repo precondition, not this.

Self-hosted is a bridge while Actions billing is unavailable. Hosted runners are the target state for anything a pull request can trigger. Moving permanently to one Mac mini converts a three-platform gate into a one-platform gate, and — once this repository is public — turns every forked PR into arbitrary code execution on a personal machine.

What to change, and what deliberately not to

release.yml first (lines 17, 86, 163 → [self-hosted, macOS, ARM64]). This is the change that pays for itself: OIDC trusted publishing works on self-hosted runners, because the token is issued by GitHub rather than the runner host. 0.5.1 shipped with attestations: none after a manual publish; this restores provenance for 0.5.2.

Fold in the attach fix while in the file — it has failed on every release, 0.5.0 and 0.5.1 included, because gh release upload runs in a job with no checkout and cannot infer the repository:

run: gh release upload "$RELEASE_TAG" "$RUNNER_TEMP"/agentcall-release/* --clobber --repo ${{ github.repository }}

gh run rerun 32048093911 verifies both without cutting a version — it will refuse to republish 0.5.1, but build proves the runner and attach proves the fix.

ci.yml: move verify only. verify is the job scripts/ci-local.sh mirrors and the one that decides whether a change ships.

Leave the other two hosted. They cannot run on one macOS ARM64 machine:

• packed-cli-consumer matrixes [macos-latest, ubuntu-latest] × node [20, 22, 24]. The Linux legs have nowhere to go, and that is the leg catching the missing-dist/ packaging trap CLAUDE.md documents. It also deliberately has no checkout, so it would inherit a dirty self-hosted workspace.
• windows-compat is windows-2025. Support Windows as a native AgentCall callee #251 and Ship a signed, unattended Windows installer #252 are open against Windows behavior; silently dropping the job is worse than leaving it queued.

Restore the triggers. Retargeting alone changes nothing while both files are workflow_dispatch: only. Delete the "Automatic runs are temporarily paused while GitHub Actions billing is unavailable" comment blocks at the same time, or they become the next stale claim someone trusts — the same failure mode inv_gate_mirrors_ci exists to prevent.

Blocking precondition on going public

The repository is private today (visibility: private), which is the only reason a self-hosted runner is acceptable here.

Once it is public, pull_request + self-hosted means any stranger's forked PR runs arbitrary code on the Mac mini — ~/.ssh, ~/.npmrc, ~/.agentcall, and the npm credentials that publish this package. verify performs a full pnpm install and runs wrangler, so such a PR gets network access and a writable store. GitHub warns against self-hosted runners on public repositories specifically.

Do not flip visibility until one of these is in place:

1. verify moved back to a hosted runner once billing is settled. Simplest, and the intended end state.
2. pull_request dropped, running on push to in-repo branches only. Loses fork-PR coverage.
3. Settings → Actions → "Require approval for all external contributors".

Option 1 is the recommendation; 2 and 3 are stopgaps if publication has to happen before billing clears.

Decided 2026-08-28: option 3, chosen deliberately, not as a stopgap.
verify stays on [self-hosted, macOS, ARM64] — moving it to a hosted
runner reintroduces the cost self-hosting was meant to avoid, and doesn't
remove the review burden anyway: a maintainer still has to read a first-time
contributor's diff before trusting a CI result, hosted or not. Required
approval makes that reading mandatory instead of optional — a forked PR's
workflow run queues until a maintainer approves it, so nothing executes on
the Mac mini before a human has looked at it. Read package.json, the
lockfile, and scripts/ especially closely before approving: verify runs
a full pnpm install and wrangler, so a malicious first PR has both
network access and a writable store once approved.

Apply before flipping visibility: Settings → Actions → General → "Fork pull
request workflows" → Require approval for all outside collaborators. No
workflow file changes needed for this — see #453 discussion.

release.yml is unaffected either way — it only fires on release: published, which is maintainer-triggered, not fork-PR-triggered.

Why this is filed rather than done

.github/workflows/ is a PreToolUse hard deny in .claude/settings.json (scripts/guard-verification-gate.sh), so an agent cannot make these edits — by design, see #335 and #374. A human applies them.

[KenTaniguchi-R]

Correction: the attach fix is already in the tree

The issue body says to add --repo ${{ github.repository }} to the gh release upload step. That edit is unnecessary — an equivalent fix landed between v0.5.0 and v0.5.1.

At v0.5.0, the step's env was:

env:
  GH_TOKEN: ${{ github.token }}
  RELEASE_TAG: ${{ github.event.release.tag_name }}

At v0.5.1 and on main today:

env:
  GH_TOKEN: ${{ github.token }}
  GH_REPO: ${{ github.repository }}      # <- added
  RELEASE_TAG: ${{ github.event.release.tag_name }}

gh reads GH_REPO as its repository selector, so it no longer needs a git checkout to resolve the target, and --repo would be redundant with it. The 0.5.0 run log confirms the variable was absent at the time — it printed only GH_TOKEN and RELEASE_TAG before failing with fatal: not a git repository.

It is untested rather than unfixed. The v0.5.1 release run never reached attach: build failed with zero steps on the Actions billing block, so publish and attach were both skipped. The first release that actually gets past build will be the first real exercise of this fix.

Practical consequence for the plan above: the remaining work is only the runs-on retargeting and the trigger restoration. Do not add --repo.

Filed on a partial reading of the failure log rather than the current file — same mistake as #443 and #444 earlier today, and the same fix: read the file at the relevant ref before asserting what it contains.

[KenTaniguchi-R]

Decision: keep self-hosted, gate with required approval

Revisiting the "do not flip visibility" list below. Decided against moving
verify back to a hosted runner (option 1) — that reintroduces the cost this
self-hosted setup was built to avoid, and doesn't remove the review
responsibility anyway (you still shouldn't blindly trust a hosted-runner CI
result on a first-time contributor's PR without reading the diff).

Chosen: option 3. Settings → Actions → General → "Fork pull request
workflows" → Require approval for all outside collaborators, applied
before the repo goes public. ci.yml / invariants.yml keep running
verify on [self-hosted, macOS, ARM64] exactly as they do today — no
workflow file changes needed for this.

This makes the approval step the actual control, not the runner choice: a
forked PR's workflow run queues until a maintainer approves it, so nothing
executes on the Mac mini before a human has read the diff — package.json,
lockfile, and scripts/ changes especially, since verify does a full
pnpm install and runs wrangler. That review has to happen for every
first-time contributor, every time; it is a discipline requirement, not a
one-time checkbox.

release.yml is unaffected either way — it only fires on release: published, which is maintainer-triggered, not fork-PR-triggered.