Cut the release tag in CI under OIDC — it is the only step in the chain still requiring a human's laptop

[bdelanghe]

The observation

mint is already a CI action almost everywhere:

step	where it runs	identity
mint plan (preview)	version.yml, workflow_call	—
mint attest + cosign signing	release-provenance.yml, workflow_call	keyless OIDC, no key material
JSR publish	consumer's publish-jsr.yml, on v* tag	OIDC
cut + push the v* tag	a human's laptop	a person's git credential

Everything downstream of the tag is already keyless and attested. The tag cut is the only step that isn't — and it's the step that starts the whole chain.

Why that's backwards

release.mjs's in-toto Statement binds tag → version plan → commit and is signed in CI by the workflow's OIDC identity. But the tag itself — the subject of that statement — is created by whoever happened to run the CLI. The provenance attests the record, not the act.

Moving the cut into a pinned workflow_dispatch job improves that rather than merely automating it. Per infra/docs/cloud-sessions.md, job_workflow_ref is load-bearing because it names reviewed, deterministic code on protected main — program attestation. A tag cut inside a pinned workflow is attested by what ran; a laptop tag is attested by who ran it.

It's also the shape the org already settled on for exactly this reason:

The correct shape is the one already in use: the session dispatches; a reviewed, pinned workflow holds the credential and does the work.

And it fits #1's direction (OIDC trusted publishing, no tokens) rather than cutting against it.

It subsumes #18's second item

#18 documents the symptom — under a ruleset restricting tag creation, git push origin v<version> is rejected even for an admin — and proposes documenting a bypass actor plus a --no-push recipe.

That's a workaround for a problem that disappears if the tag is cut by a workflow: the workflow's github.token is an installation token that can be granted tag-creation directly, and there's no standing human credential to bypass anything with. #18's item 1 (bootstrapping a first release) is orthogonal and still worth documenting.

Fresh evidence, 2026-07-31

Hit this cutting drift-gate v0.3.0. mint version and the PR merged fine; mint release did this:

mint: created signed tag v0.3.0
error: RPC failed; HTTP 403
fatal: the remote end hung up unexpectedly

Isolated rather than assumed: a branch push to the same remote succeeded seconds later, and the tag push failed identically on retry. So the refusal is specific to refs outside refs/heads/*.

Different mechanism from #18 — that's an org ruleset, this is a Claude Code session's git proxy — but the same shape: the release stalls at exactly the one step that needs a credential no automated context has. drift-gate 0.3.0 is merged, version-bumped, changelog-written, jsr publish --dry-run green, and unreleasable without someone opening a laptop.

That also blocks a downstream security fix: conformance can't clear its brace-expansion advisory until drift-gate 0.3.0 reaches JSR (ci-workflows#8).

Shape worth considering

A reusable release-cut.yml (workflow_call + consumer workflow_dispatch) that:

1. verifies the manifest version has no existing tag (fail closed — never overwrite a published version)
2. verifies .release/ is empty, i.e. mint version has already been applied and merged
3. re-derives the statement and checks it matches the merged commit
4. creates and pushes the annotated tag with github.token
5. lets the existing publish-jsr.yml / release-provenance.yml fire as they do today

Steps 1–3 are things the CLI checks locally today; in CI they'd be enforced rather than trusted.

Open questions

• Trigger: workflow_dispatch (a human or a session dispatches, workflow does the work) vs. automatic on merge when .release/ has intents. Dispatch keeps a decision point in front of an immutable JSR publish, which argues for it.
• Confirmation input: require the expected version as a dispatch input and fail if it doesn't match the manifest? Cheap guard against dispatching the wrong thing.
• Tag signing: the CLI signs the tag when git signing is configured. A workflow has no signing key — but it has OIDC and cosign, and the release Statement is already the stronger attestation. Worth deciding explicitly whether the tag itself still needs a signature or whether the signed Statement supersedes it.
• Does the CLI path stay? Probably yes for local/bootstrap use (#18 item 1), but it should stop being the expected path.

One thing this must not become

cloud-sessions.md argues against giving an agent Actions OIDC, because "a workflow whose job is 'run an agent' presents an identically-shaped claim while its actual behaviour is whatever the conversation directs."

This is the opposite of that. A release-cut workflow runs pinned, deterministic code against repo state — it's the reviewed-program side of that distinction, not the agent side. Worth stating in the implementation so the two don't get conflated later.

[bdelanghe]

Blocker found before implementing: a GITHUB_TOKEN-pushed tag triggers nothing

Started building this and hit the thing that would have made the naive version silently useless. Recording it because it changes the design, not just the code.

GitHub does not create workflow runs from events caused by GITHUB_TOKEN (the documented exceptions are workflow_dispatch and repository_dispatch). Every consumer's downstream release machinery fires on a tag push — drift-gate is representative:

# publish-jsr.yml
on:
  push:
    tags: ["v[0-9]+.[0-9]+.[0-9]+"]

# release.yml  → mint/release-provenance.yml
on:
  push:
    tags: ["v*"]

So a release-cut.yml that cuts the tag with the workflow's own token would produce: a tag, a green workflow, no JSR publish, and no signed provenance. Worse than the status quo, because it looks like it worked — the exact green-but-does-nothing shape that required-baseline.yml and adoption grace both had.

What this rules out

Not "give the workflow a PAT or App token so the push looks human." That reintroduces the standing credential the whole design exists to remove, and it would make the tag's provenance worse than the laptop tag it replaces.

The design that survives it

release-cut.yml stays single-purpose — guards + tag, with the version and tag as outputs — and the consumer chains the downstream work as dependent jobs in the same run rather than relying on tag-push triggering:

# consumer .github/workflows/release-cut.yml
on: workflow_dispatch
jobs:
  cut:
    uses: bounded-systems/mint/.github/workflows/release-cut.yml@<sha>
  publish:
    needs: cut
    permissions: { id-token: write, contents: read }
    # npx jsr publish at the cut tag
  provenance:
    needs: cut
    permissions: { id-token: write, contents: write }
    uses: bounded-systems/mint/.github/workflows/release-provenance.yml@<sha>

Consequences worth deciding on:

• Consumers keep their tag-triggered workflows for laptop-cut releases, so both paths work during migration — but a tag cut in CI runs the chained jobs, and a tag cut locally runs the triggered ones. Two paths to the same outcome is a thing to document loudly or it becomes the next stale record.
• release-cut.yml must state this constraint in its header. A consumer who wires it up expecting push: tags to fire gets a silent no-op, and nothing in CI would flag it.
• Alternatively the reusable workflow could own publish + provenance itself, so consumers get one job instead of three. Cleaner call site, but it duplicates publish-jsr.yml and couples mint to each ecosystem's publish command — probably wrong for a tool that already stays ecosystem-agnostic.

Also relevant: #11's cooldown is narrower than it looks

Releasing drift-gate 0.3.0 and immediately bumping conformance to it hit minimumDependencyAge — deno refused to resolve a version published minutes earlier.

But it does not block CI. With a cold DENO_DIR, a committed lockfile, and no override flag, deno check exits 0. The policy gates resolution, not installation from an existing lock. So the workaround is a one-off --min-dep-age 0 when relocking, with the flag deliberately not persisted and minimumDependencyAge left unset — the control stays fully in force afterwards, and CI needs no waiver.

Worth folding into #11: the cooldown costs one flag at relock time, not a 24h stall on the whole batch.

---

Generated by Claude Code

[bdelanghe]

A third option that avoids both the credential and the chaining

prx hit this independently while cutting v1.0.0 and has now implemented it (prx#1068 → prx#1069, merged). Reporting back because the shape we landed on isn't either of the two considered above, and it may simplify the consumer story here.

Same wall, same isolation. HTTP 403 on the tag push; a branch push to the same remote succeeded seconds earlier; identical on retry. Exactly the diagnosis in the issue body.

The option: cut the tag with github.token as designed, then workflow_dispatch the downstream workflow at the new tag. The blocker comment already names why this is available — "the documented exceptions are workflow_dispatch and repository_dispatch" — but reads them as exceptions that don't help. They do, if you dispatch at the tag ref rather than trying to make the push itself trigger.

Verified before building on it, since the whole design rests on it. Dispatching a workflow at an existing tag ref:

head_branch=v0.29.0  sha=cf6be79  event=workflow_dispatch

So github.ref resolves to refs/tags/<tag> and ref_name to the tag, and the tag's commit is checked out. That means a downstream workflow's tag-only logic works unchanged — in prx's case release-binary.yml's ver="${GITHUB_REF_NAME#v}", its two startsWith(github.ref, 'refs/tags/') guards, and 9 GITHUB_REF_NAME uses, none of which needed touching.

What it buys over chaining:

• No refactor of the downstream release workflow — which matters most where that workflow is the one thing you can't test end to end without publishing.
• Consumers keep a single downstream workflow on on: push: tags, serving both the CI cut and a laptop cut. The "two paths to the same outcome" documentation burden in the bullet above mostly goes away — there's one path, entered two ways.
• No PAT and no App token, so the rejection above stands untouched. The only permission added is actions: write on the cutting job, to dispatch.

Honest limits:

• The downstream run is dispatched, not push-triggered. Anything keying specifically off the push event payload still won't see it. For a build-and-publish job keyed off the ref, that's immaterial; for something inspecting github.event.head_commit or similar, it isn't.
• It needs actions: write, which chaining doesn't.
• prx's downstream already accepts workflow_dispatch. A consumer whose release workflow is on: push: tags only would need that trigger added — one line, but not zero.

Also worth checking here: the guard-3 edge

prx's first real dry-run blocked on its own changeset, and the guard was wrong. It counted every pending intent file, but an empty changeset is prx's convention for a change with no package codepath (CI-only, test-only), which carries no version intent — so by the guard's own rationale ("the manifest is behind the intents") nothing was behind anything. Left alone it would have forced a no-op version PR before every release following a CI-only change. Fixed in prx#1071 by counting only intents that declare a bump.

If mint's .release/ model has an equivalent no-op intent, its guard likely has the same edge. If it has no such concept this doesn't apply — flagging rather than assuming, since I haven't read that part of mint.

Worth stating plainly: prx's path is not end-to-end proven either. dry-run: true passes all four guards, but no tag has been cut — the tag-creation grant (#18) is still outstanding there too. So this is a verified mechanism inside an unverified whole, the same caveat mint#23 made about itself.

---

Generated by Claude Code

[bdelanghe]

Following up: prx is diverging from the App-token rejection, and should say so

prx has decided to cut its release tag with a broker-minted App identity (prx#1073) — which is the thing this issue rules out:

Not "give the workflow a PAT or App token so the push looks human."

Flagging it here rather than quietly diverging, since this is a merged design decision and the reasoning above is sound for the case it was written against.

Where the disagreement actually is: the premise, not the conclusion. The objection is that such a token "reintroduces the standing credential the whole design exists to remove" and makes the tag's provenance "worse than the laptop tag it replaces". Both hold for a PAT, and for an App token minted from a PEM in repo secrets. Neither seems to hold for a broker mint:

• Not standing. Short-lived and OIDC-gated; the App key lives behind the broker, not in the consumer repo. The mint is itself gated on job_workflow_ref — so the capability is bound to reviewed, pinned code on protected main. That is the same program-attestation property this issue argues for, applied one layer earlier: not just "the tag was cut by a pinned workflow" but "only a pinned workflow could obtain the ability to cut it".
• Not worse provenance. That reads as assuming a general-purpose App identity shared across workflows. A capability-named entry pinned to one workflow — the shape front-desk-claim already has here, and /github/forge-version has in prx — attributes more precisely than a human's key, not less.

Worth noting prx currently has a live example of the version this issue is right about: release-binary.yml still reads PRX_FORGE_APP_PRIVATE_KEY from repo secrets (prx#1072). That is a standing credential, and it is exactly what the rejection should keep out. The broker path is what removes it.

The practical payoff, and why prx isn't just taking the convenient option: an App-pushed tag triggers on: push: tags natively, so the workflow_dispatch-at-tag step from my earlier comment gets deleted. Consumers keep one trigger on their release workflow, and the "two paths to the same outcome — document it loudly or it becomes the next stale record" concern in the original blocker comment never arises. Fewer moving parts than either option currently on the table here.

So: if the rejection was aimed at repo-held key material rather than at App identities as such, mint's own release-cut.yml could drop the consumer-chaining requirement the same way. If it was aimed at App identities regardless of how the token is obtained, I'd like to understand that argument better — prx is diverging on the reading above, and it would be better for both repos to land in the same place.

---

Generated by Claude Code