fix(remote-worker): bake a system git identity into the sandbox image

[pdettori]

Fixes #415.

Problem

An agent's first git commit in a sandbox failed with exit 128 ("Please tell me who you are") until it configured an identity itself — observed live on the VM demo (docs/demos/vm-multi-user-demo.md, fix list 5), on both P4 sessions and on the container tier. Each workaround cost a tool call and a model round, in front of an audience.

Fix

A system gitconfig (/etc/gitconfig: user.name = MOCA sandbox, user.email = sandbox@moca.invalid) baked into both leaf images (remote-worker/Dockerfile, Dockerfile.runtime), exactly as the issue proposes:

• Applies to any uid the images can run as — including the arbitrary gid-0 uid under nonroot-v2 that feat: per-user inference credential headers and sandbox research tooling (#368 phase 1) #372's writable HOME prepares but cannot pre-configure.
• A user's or agent's own higher-precedence config still overrides both fields — a floor, not a ceiling.
• The P4 rootfs inherits it for free, being exported from this image by build-rootfs.sh.

Guards (per the issue)

• research_tooling_test.go:
  • a static pin of the exact RUN printf instruction in both files, and its position before the USER 1001 drop;
  • a runtime check that extracts the printf's format string, installs it as a scratch environment's only git config, and runs a real no-prior-config commit — so a gitconfig the line still prints but git silently ignores (typo'd section header, literal \\t) fails CI, not the next demo.
• build-snapshot.sh: check_git_identity runs a real empty commit (with user.useConfigOnly=true, so an unconfigured git fails instead of auto-guessing an identity) in the booted guest of both VMM arms, after probe_capabilities, before quiesce_guest. A rootfs built from an image that lost its gitconfig now fails the snapshot build at build time. build-snapshot.test.sh pins the gate's contract (existence, both arms, probe→check→quiesce order, useConfigOnly, real commit).

Verification

• go test ./... in remote-worker passes; the new guards were mutation-tested (commented-out RUN, RUN-after-USER, typo'd section header each fail the respective test).
• hadolint clean on both Dockerfiles; shellcheck -S warning clean.
• build-snapshot.test.sh 209 ok / 0 fail; build-rootfs.test.sh PASS.

🤖 Assisted-By: Claude Code

[ingpaolodettori-dev]

Summary

This bakes a system /etc/gitconfig (MOCA sandbox <sandbox@moca.invalid>) into both leaf images, so an agent's first git commit no longer exits 128. It adds two guards: a Go static pin plus a runtime check, and a snapshot-build gate that runs a real commit with useConfigOnly in the booted guest. I checked that guest_client passes the guest command's exit code through (os.Exit(e.ExitCode)), so the gate does fail closed. I found no blocking issues. Two suggestions: (1) the gate's /tmp/id-check repo gets captured into the memory snapshot and so ships in every restored sandbox, and (2) the Go runtime test should pin useConfigOnly and assert the resulting identity, so it can't pass on git's auto-detected identity.

Author: pdettori (MEMBER — maintainer)
Areas reviewed: Dockerfile, Shell, Go tests, Security
Agent/IDE config (.claude/.vscode): none
Commits: 1 commit, all signed-off: yes
CI status: passing (14/14, including hadolint, shellcheck, microvm-gates, k8s-kind-e2e)

[ingpaolodettori-dev]

suggestion — The repo this check creates ends up in every restored sandbox. check_git_identity runs before quiesce_guest and the snapshot. The snapshot captures guest RAM (mem_backend / memfile), and that includes the /tmp tmpfs. So every VM restored from this snapshot boots with /tmp/id-check, which holds a MOCA sandbox commit. The comment at L841 ("the throwaway repo leaves no trace") is only true for a cold boot, not for a snapshot restore.

You could remove it inside the same guest command and keep the commit's exit code:

-command 'git init -q /tmp/id-check && cd /tmp/id-check && git -c user.useConfigOnly=true commit --allow-empty -m x 2>&1; rc=$?; cd / && rm -rf /tmp/id-check; exit $rc'

It's also worth a build-snapshot.test.sh check that pins the rm -rf /tmp/id-check, and a fix to the L841 comment.

[ingpaolodettori-dev]

nit — 2>/dev/null throws away guest_client's own diagnostics (dial or CONNECT failures, guest error: …). A transport failure then gets reported as "the guest git has no usable identity", with an empty Guest output:. The guest command already merges its own stderr with 2>&1, so you could capture host-side stderr as well (2>&1) to make the error message accurate in both cases.

[ingpaolodettori-dev]

suggestion — This runtime check can pass without testing anything, which is the same failure mode the shell gate avoids with user.useConfigOnly=true. When git has no user.name/user.email, it doesn't fail outright. It falls back to an identity built from the passwd entry and the hostname, and it only refuses when that email isn't fully qualified. On a host whose hostname resolves to an FQDN (many CI runners and dev machines), a broken baked gitconfig (typo'd [user] header, literal \t) still commits. The test then passes, so it doesn't catch the drift its doc comment says it catches. Separately, GIT_CONFIG_SYSTEM needs git ≥ 2.32. Older git ignores it and reads the host's /etc/gitconfig.

Two changes would close both gaps:

{"-c", "user.useConfigOnly=true", "commit", "--allow-empty", "-m", "#415"},

and then assert the identity that was actually used:

out, err := run("log", "-1", "--format=%an <%ae>")
// want "MOCA sandbox <sandbox@moca.invalid>"

(Today the static systemGitconfig pin catches these mutations, but only because it pins the exact bytes. The runtime test should hold up by itself.)