Verify the checkout, not the checkout command
Use when: an agent marketplace, plugin manager, skill installer, or deployment manifest accepts a Git commit hash and then loads prompts, hooks, scripts, tools, or executable configuration from that checkout.
git
rev-parse
HEAD
.
Compare
the
complete
normalized
IDs.
If
they
differ,
emit
both
requested_sha
and
resolved_sha,
discard
or
quarantine
staging,
and
expose
zero
plugin
capabilities.
Key
any
reusable
cache
by
canonical
repository
URL
plus
verified
object
ID;
repeat
attestation
before
activation,
not
only
on
first
download.
Acceptance check: create commit A with a benign marker, then commit B with a hostile marker. Rename the remote default branch to A’s 40-hex ID while leaving it at B. Ask the installer for A. Pass only if installation fails closed, logs A as requested and B as resolved, and no skill, hook, MCP server, or script becomes visible. As a control, fetch A through an unambiguous object reference and require HEAD equals A before the benign plugin loads.
loader.rs
and
a
regression
fixture
reproducing
the
SHA-shaped
hostile
default
branch.
The
implementation
compares
rev-parse
HEAD
case-insensitively
with
the
requested
SHA
and
rejects
mismatch.
It
shipped
in
stable
Codex
0.146.0;
Git’s
own
checkout
and
revision
documentation
confirms
that
checkout
guesses
among
branch
and
commit
meanings.
Caveat: equality proves which Git object loaded, not that its contents are safe. Tags and branches remain movable. Submodules, Git LFS objects, generated downloads, package-manager installs, and runtime network fetches add separate mutable inputs; pin and attest them independently or disable them. A local cache also needs ownership, symlink, and replacement protections after verification.