Code agent: use GitHub commit API for verified commits

[rh-hemartin]

Problem

Commits made by the code agent via git commit in the runner shell are unverified on GitHub. GitHub has no way to confirm the committer identity, so they show up without the "Verified" badge. This makes agent commits harder to trust at a glance and inconsistent with signed human commits.

Benefit

Since the code agent is the default agent for all users, this change means every commit produced by a fullsend agent run gets the "Verified" badge automatically, with no GPG key setup or signing configuration required. Users get verified agent commits out of the box.

Proposed change

Replace the local git commit workflow with the GitHub Git database API to create commits server-side. GitHub automatically marks commits created through its API as verified.

The rough flow:

1. After the agent finishes its changes, compute the tree (blobs + tree object) from the working directory diff.
2. Call POST /repos/{owner}/{repo}/git/blobs for each changed file.
3. Call POST /repos/{owner}/{repo}/git/trees to build the new tree.
4. Call POST /repos/{owner}/{repo}/git/commits with the tree SHA, parent SHA, message, and author/committer info.
5. Call PATCH /repos/{owner}/{repo}/git/refs/heads/{branch} to update the branch ref.
6. Reset the local checkout to match (git fetch + git reset).

Scope

This affects the commit path in the code agent (agents/code.md, skills/code-implementation/SKILL.md) and the post-run scripts that amend commits (scripts/post-code.src.sh, scripts/post-fix.src.sh).

Prior art

This approach has been tested in rh-hemartin-fullsendai/standalone-fullsend#69. The commit 673b1f0 created by the agent through the API shows as verified. The workflow run that produced it: https://github.com/rh-hemartin-fullsendai/standalone-fullsend/actions/runs/29906968309

Notes

• The GITHUB_TOKEN available in Actions already has the necessary permissions for the Git database API.
• Author and committer fields in the API call should match what the agent currently uses.
• The post-code scripts that run git commit --amend --no-edit (for lint fixes, formatting, etc.) also need to go through the API path or be restructured to fold changes before the single API commit.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 9:34 AM UTC · Completed 9:38 AM UTC
Commit: 7ada4e0 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: Medium · Category: Feature

Problem

Commits created by the code agent via local git commit appear as unverified on GitHub. GitHub cannot confirm the committer identity without GPG signing or API-based commit creation, so agent commits lack the "Verified" badge — reducing trust and consistency with signed human commits.

Root Cause

Local git commit produces unsigned commits. The sandbox environment has no GPG keys. The GitHub Git database API automatically marks commits it creates as verified, making it the simplest path to verified agent commits.

Recommended Approach

Replace local git commit + git push in post-code.src.sh and post-fix.src.sh with GitHub Git database API calls:

1. Create blobs for changed files
2. Build a tree object
3. Create the commit with parent SHA and message
4. Update the branch ref
5. Reset the local checkout via git fetch + git reset

A shared library under scripts/lib/ (e.g., git-api.lib.sh) would allow both post-code and post-fix to reuse the API commit logic. The post-fix --amend workflow needs restructuring to fold changes before the single API commit rather than amending locally.

The prior art in rh-hemartin-fullsendai/standalone-fullsend PR #69 provides a working reference — commit 673b1f0 created through the API shows as verified.

Proposed Test Case

In post-code-test.sh and post-fix-test.sh:
1. Mock GitHub API endpoints (blobs, trees, commits, refs)
2. Verify correct API call sequence and payloads
3. Verify ref update targets the correct branch
4. Verify local checkout resets after API commit
5. Edge: empty diff skips API calls
6. Edge: binary files use base64 blob encoding
7. Post-fix specific: amend-style flows fold into single API commit

Related

• Issue Add commit_message field to upstream code-result.schema.json #356 (add commit_message to code-result schema) is independently valuable and could land in parallel — the API commit flow will consume the same commit_message field from agent output.

---

Labels: This is a feature request affecting the code agent's commit path. The code-agent label matches the primary component, and enhancement matches the feature category.

[rh-hemartin]

@lahavyuv86 I had some questions and some feedback from the team:

• Why has value that bots sign their commits?
• How does this work on GitLab?
• This should be able to handle "/fs-fix rebase this" and other more complex cases
• This should be offered as a skill or a customization to keeping the normal behavior

[lahavyuv86]

Hi @rh-hemartin, so some of the questions I can answer:

• Our github org doesn't allow commits that doesn't have the "verified" badge on a signed commit to be merged (@schmidtd can share more information on that)
• At a first glance gitlab also have their own commits api (https://docs.gitlab.com/api/commits/), there's a way to search for env vars such as GITHUB_ACTIONS=true and GITLAB_CI=true (in case the script runs inside a CI/CD pipeline) to determine which git system we target, there's also other ways to determine like have a kind of pre-flight check based on the target url.
• Regarding the complex cases I understand this has a wide impact on the fullsend product, would that be something your team need to prioritize?

[rh-hemartin]

• Related with GitLab... yes, as per this comment the commit API on GitLab should be used to get commits verified. And yes, we could scan those variables to know where the agent is.
• As for the complex cases, yes it is something that has a wide impact and a lot of us are instructing /fs-fix to rebase, etc. It is doable, of course, but we may need to resort to other's tooling instead of having the burden of maintaining it ourselves. There is this "gh commit" extension that could be useful, I think it supports those cases. Could you take a look at that?
• Potentially you could be using this approach described on the issue (and implemented on https;//github.com/rh-hemartin-fullsendai/standalone-fullsend) for your code agent if you want to onboard some real repositories (maybe cloned for testing). You could then contribute it back to core fullsend so more users can benefit.

[fullsend-ai-prioritize]

RICE Priority Score: 0.9

Score breakdown

Dimension	Score	Reasoning
Reach	2	The code agent is the default agent for all users, so every agent-produced commit would benefit from the Verified badge. At least one org explicitly blocks merging unverified commits, and many enterprise GitHub orgs have similar branch protection rules. Score 2 (most active users across orgs).
Impact	1.5	For orgs that require commit signing via branch protection, agent commits are currently unmergeable — a blocking workflow issue. For other users, unverified commits reduce trust and create inconsistency with signed human commits. Score 1.5 (significant pain point, blocking for some).
Confidence	0.6	The issue is well-described with working prior art (PR #69, commit 673b1f0), but the comment thread significantly expanded scope: GitLab support, complex rebase cases, and skill/customization architecture. This scope creep introduces uncertainty in both Reach (GitLab users) and Effort. Score 0.6 (reasonable understanding but gaps remain).
Effort	2	Requires replacing the commit path in multiple scripts (post-code.src.sh, post-fix.src.sh), creating a shared API library, restructuring the post-fix amend workflow, and handling edge cases (binary files, empty diffs). Comments add GitLab API support, complex git operations (rebase), and a skill/customization pattern. Score 2 (significant implementation, multiple components, cross-platform concerns).

Formula: (2 x 1.5 x 0.6) / 2 = 0.9