[BUG] Remote/cloud environments provision an empty commit-signing public key, causing all commits to show as "Unverified" on GitHub

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Every commit made in this remote/cloud session shows as "Unverified" on GitHub, even though git config shows commit signing correctly configured. Root cause, diagnosed directly in-session:

git config --global --list shows commit.gpgsign=true, gpg.format=ssh, gpg.ssh.program=/tmp/code-sign, user.signingkey=/home/claude/.ssh/commit_signing_key.pub, user.email=noreply@anthropic.com, user.name=Claude — all correctly set, both globally and per-repo.
/home/claude/.ssh/commit_signing_key.pub is empty (0 bytes). ls -la shows a timestamp of March 31, months before this session started — it's a stale placeholder from the base container image, not something generated at session start.
/tmp/code-sign (the configured gpg.ssh.program) is a symlink to /opt/env-runner/environment-manager, created fresh at this session's start (today's timestamp). Invoking it directly with -Y sign -n git -f /home/claude/.ssh/commit_signing_key.pub against test input returns Error: no file specified to sign — the signing tool itself runs, but has nothing valid to sign with.
Net effect: git log --format='%G?' reports N (no signature) for every commit on the branch, despite commit.gpgsign=true.
This matches issue #73259 exactly (same empty-key-file symptom, tagged area:security/bug/needs-repro, marked as a regression, closed "not planned" July 2). Filing this as a fresh report with a concrete repro and additional evidence:
This account/environment had been working correctly (commits signing and showing as "Verified") for approximately 2 months, and only started failing in the last 2 days — consistent with the "Regression: Yes (worked in a previous version)" note on #73259, suggesting whatever provisions the signing key broke recently rather than being permanently broken.
Git version in the affected environment: 2.43.0.

What Should Happen?

At session/environment start, the provisioning step that installs the real SSH commit-signing key pair (public key at user.signingkey's path, matching private key available to gpg.ssh.program) should run successfully and overwrite the placeholder, the same way it evidently did for the ~2 months before this regression. Commits made in a remote/cloud session with commit.gpgsign=true configured should sign successfully and show as "Verified" on GitHub — not silently produce unsigned commits with no error surfaced to the user or the agent.

Error Messages/Logs

Stop hook feedback:
[~/.claude/stop-hook-git-check.sh]: There are commit(s) on branch '<branch>' that GitHub will show as Unverified (missing signature, or committer email is not noreply@anthropic.com):
<commit-hash> N noreply@anthropic.com
...
Please run 'git config user.email noreply@anthropic.com && git config user.name Claude', then 'git commit --amend --no-edit --reset-author' for the tip commit, or 'git rebase --exec "git commit --amend --no-edit --reset-author" origin/HEAD' for earlier commits, then push.

$ git config --global --list
user.name=Claude
user.email=noreply@anthropic.com
user.signingkey=/home/claude/.ssh/commit_signing_key.pub
gpg.format=ssh
gpg.ssh.program=/tmp/code-sign
commit.gpgsign=true
...

$ ls -la /home/claude/.ssh/
total 8
drwxr-xr-x 2 claude claude 4096 Mar 31 13:31 .
drwxr-xr-x 6 claude claude 4096 Jul 10 17:06 ..
-rw-r--r-- 1 claude claude    0 Mar 31 13:31 commit_signing_key.pub

$ ls -la /tmp/code-sign
lrwxrwxrwx 1 root root 35 Jul 18 01:24 /tmp/code-sign -> /opt/env-runner/environment-manager

$ echo "test" | /tmp/code-sign -Y sign -n git -f /home/claude/.ssh/commit_signing_key.pub
Error: no file specified to sign
Usage:
  environment-runner code-sign [flags]

Flags:
  -h, --help   help for code-sign

Error: no file specified to sign

$ git log --format='%h %G? %ce' origin/HEAD..HEAD
<hash1> N noreply@anthropic.com
<hash2> N noreply@anthropic.com
...
$ git --version
git version 2.43.0

Steps to Reproduce

Start a Claude Code remote/cloud session (Claude Code on the web) against a repository with a GitHub remote. Have the agent make one or more commits and push them to the branch. View the commits on GitHub — they show as "Unverified" despite the repo/environment having commit signing configured. Inside the session, run git config --global --list — confirms commit.gpgsign=true, gpg.format=ssh, user.signingkey, and identity are all correctly set. Run ls -la on the path in user.signingkey (e.g. ~/.ssh/commit_signing_key.pub) — the file exists but is 0 bytes, with a stale timestamp far older than the session (in this case, March 31, vs. session start in July). Run git log --format='%G?' on any commit made this session — reports N (unsigned) for all of them. This account/environment previously produced correctly signed/"Verified" commits for approximately 2 months; the empty-key/unsigned-commit behavior only began in the last 2 days, suggesting a recent regression in the key-provisioning step rather than a permanent misconfiguration.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.22209.0 (77c938)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This is a duplicate/related report to #73259 (same empty-key symptom, tagged area:security/bug/needs-repro, closed "not planned" July 2). Filing fresh rather than commenting there since that thread lacked a concrete repro; this one includes direct in-session diagnosis plus new regression-timing evidence.
Not repo-specific: the same empty commit_signing_key.pub / unsigned-commit behavior reproduced identically across two unrelated repositories accessed in the same session, pointing to an account/environment-level signing-key provisioning failure, not something scoped to a particular repo's settings.
Two different components, two different ages: /tmp/code-sign (the signing helper, symlinked to /opt/env-runner/environment-manager) is recreated fresh at each session start — its timestamp matches session start time exactly. But ~/.ssh/commit_signing_key.pub carries a stale March 31 timestamp, months old. This suggests session bootstrap generally works fine, and the specific failure is isolated to whatever step is supposed to generate/install a real key pair over that placeholder file.
No client-side workaround exists: within the session, git config already showed fully correct values (commit.gpgsign=true, gpg.format=ssh, correct user.signingkey path, correct user.name/user.email) — the gap is purely the missing key material itself, which isn't something fixable via git configuration from inside the session.
Silent failure, easy to miss: nothing in normal Claude Code usage surfaces that commits aren't being signed — this was only caught because the repo had a custom local Stop hook explicitly checking git log --format=%G? after every commit. Without that hook, this would likely go unnoticed indefinitely.
Timeline: this account/environment produced correctly signed ("Verified") commits for approximately 2 months, with the failure starting only in roughly the last 2 days (around July 16, 2026) — consistent with #73259's own "Regression: Yes" tag, suggesting an active, still-ongoing regression rather than a permanently broken setup.