Signed commits already exist — the gap is enablement and discoverability

Good news: Pullfrog has full signed-commit support built in. It's gated behind a repository setting, signedCommits, which defaults to false and is supplied by the Pullfrog backend — which is why it isn't visible as an action input or in the docs.

How it works when enabled (utils/apiCommit.ts:270, createSignedCommit): instead of git commit + git push, the agent gets a commit_changes MCP tool that builds the commit through the GitHub Git Data API (git/blobs → git/trees → git/commits → git/refs). Because no author/committer fields are sent (utils/apiCommit.ts:341), GitHub signs the commit server-side as the app — it lands with the Verified badge. No GPG or SSH key management is needed anywhere.

The rest of the wiring is already in place: tool registration (mcp/server.ts:211), blocking of git commit / git merge / push_branch on same-repo branches so the agent can't fall back to unsigned commits (mcp/git.ts:468, mcp/git.ts:1001, mcp/git.ts:1015), signing-specific agent instructions (utils/instructions.ts:347), and signing-aware mode playbooks (modes.ts:86).

Why you couldn't find it

Two separate problems, only one of which lives in this repo:

No self-serve toggle in the action. signedCommits is read straight off runContext.repoSettings (main.ts:462, main.ts:493, main.ts:615). Unlike push, shell, and progress_comments, there is no signed_commits action input, so a workflow author cannot turn it on. It has to come from the backend.
The console toggle is server-side. The settings UI lives in a different codebase, so I can't verify from here whether the toggle is exposed, hidden, or allowlisted. That needs a maintainer to confirm.
Zero documentation. No mention in README.md, and no test coverage for signedCommits or commit_changes anywhere in the suite.

Plan

1 — Add a signed_commits action input

Four sites, following the effort reference implementation:

action.yml — new input alongside push / progress_comments
utils/payload.ts:22 area — a SignedCommitsInput = type.enumerated("disabled", "enabled"), added to the Inputs schema (utils/payload.ts:80)
utils/payload.ts:182 — the core.getInput("signed_commits") call in resolveNonPromptInputs()
utils/payload.ts:251 — a resolved signedCommits field

Then repoint the three runContext.repoSettings.signedCommits reads in main.ts (462, 493, 615) at the resolved payload field so the input actually takes effect.

Design decision to settle first: what precedence should the input have? push / progress_comments let the input override the repo setting in either direction. But signed commits is a merge gate, so the safer model is the one approvalCheck uses (utils/payload.ts:293): OR rather than override — the input can only ever turn signing on, never off. That prevents a workflow edit from silently downgrading a repo whose branch protection requires signatures. The cost is that disabling then requires a console change. I'd recommend the OR semantics and would want a maintainer to confirm before implementing.

2 — Document it in README.md

A short section covering: what the setting does, both ways to enable it, the Verified badge, and the two behavioural consequences users will notice — git commit and push_branch are deliberately blocked on same-repo branches, and fork PRs cannot be signed (the app can't API-commit to a contributor's fork, so those commits stay unsigned; see mcp/git.ts:464). That fork caveat matters for anyone enforcing signatures on a repo that takes outside contributions.

3 — Add test coverage

There is currently none. Add to utils/payload.test.ts for the input resolution and precedence, and to mcp/git.test.ts for the guard rails that block commit / merge / push in signed mode.

4 — Console follow-up (not this repo)

Confirm the repo setting is surfaced in the Pullfrog console and labelled so it's findable. I can't action this from here.

What I need before implementing

Confirmation on the precedence question in step 1 (OR-only vs full override), and whether the console toggle already exists — if it does, step 1 may be a convenience rather than the actual fix, and enabling it on the affected repos unblocks the immediate need today.

If you want to try it right now on one repo, a maintainer flipping signedCommits server-side should be enough — the action-side implementation is complete and shipped.

^{｜ Implement plan ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using Claude Opus (free via Pullfrog for OSS) ｜ 𝕏}

Uh oh!

Signed commits support #74

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions