The gpg.ssh.allowedSignersFile error and %G?=N mean git cannot verify locally, not that the commit is unsigned. Add how to confirm via gpgsig header and how to enable local verification.
3.1 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| git-commit-signing | Commits sign in-sandbox via ssh-agent (allowAllUnixSockets + inlined pubkey); local verify shows sig=N without an allowedSignersFile but the commit IS signed. |
|
Lyra's git is configured to SSH-sign commits (commit.gpgsign=true, gpg.format=ssh). The sandbox masks ~/.ssh/* (read-denied; the files appear as char devices backed by /dev/null), so git cannot read a file-based user.signingkey and ssh-keygen cannot read the private key directly. Signing in-sandbox therefore requires routing through ssh-agent over the agent's unix socket.
Working setup (as of 2026-06-02):
- NixOS / home-manager runs an ssh-agent so
/run/user/1000/ssh-agentexists andSSH_AUTH_SOCKis exported into the sandbox env. ~/.claude/settings.jsonhassandbox.network.allowAllUnixSockets: trueto let the sandboxconnect()to that socket. On Linux/WSL2 this is the ONLY available switch — the per-pathsandbox.network.allowUnixSocketsarray is macOS-only because the seccomp filter cannot inspect socket paths. Tradeoff: every unix socket on the host (including/var/run/docker.sockif present, DBus, etc.) becomes reachable from sandboxed commands.user.signingkeyset to the inlined pubkey:git config --global user.signingkey "key::$(cat ~/.ssh/id_ed25519.pub)". Must run with DOUBLE quotes outside the sandbox so$(...)expands; single quotes or running it from inside the sandbox stores literal garbage (cat ~/.ssh/id_ed25519.pubreads/dev/nullin-sandbox).
Why: removes the per-commit ! git commit ... friction; private key stays in the agent, never enters the sandbox.
How to apply: Commit normally with git commit. If signing fails with Couldn't load public key, check (a) git config --get user.signingkey starts with key::ssh-ed25519 AAAA... (not literal $(...)), (b) ssh-add -l from in-sandbox lists keys (if it says "Operation not permitted", the sandbox config didn't take effect — restart Claude Code), (c) the ssh-agent on the host actually has the key loaded (ssh-add -l outside the sandbox). Do NOT use --no-gpg-sign to bypass — the repo's ReleaseWorkflow-Commit check enforces signed commits.
Verifying — the recurring trap: git log --show-signature and the %G? format both report N and print error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification. This does NOT mean the commit is unsigned — it means git has no local allowed-signers file to check it against. The signature is present. Confirm the real state with git cat-file commit <ref> | grep -i '^gpgsig': an -----BEGIN SSH SIGNATURE----- block means signed. So N here is cosmetic, not a signing failure — do not "fix" it by re-committing. To make local verification actually pass, set gpg.ssh.allowedSignersFile to a file mapping the signer to the pubkey (a line like emma.thorpe@cloud.com ssh-ed25519 AAAA...); Gitea/CI verifies server-side regardless.
Related: git-network-ops, git-conventions.