Git delivery honors local aliases and hooks in scanned project checkouts

Summary

Git delivery runs git -C <project-root> … for every discovered session project. The runner blocks a denylist of network/mutating verbs and caps output, which is good, but it still honors local repository config.

Git aliases in .git/config override builtins, including rev-parse, reflog, and config. A project checkout whose local config contains alias.rev-parse = !… will execute that command as the Token Meter user on the next scan.

git_delivery_candidates() feeds session project paths straight into that runner (token_meter/app.py). Those paths are whatever the coding agent recorded, including untrusted clones.

Vanilla git clone from GitHub does not copy the remote’s local config, so this is not “clone and instantly RCE.” It is execution of local aliases/hooks in any tree Token Meter decides to scan (poisoned config from an install script, a copied .git, or an earlier compromise).

Where

• token_meter/services/git_delivery.py (_subprocess_runner, _run_git)
• token_meter/app.py (git_delivery_candidates)

The denylist also omits verbs such as merge / add (current callers do not use them; still defense in depth).

Suggested fix

Invoke git with GIT_CONFIG_GLOBAL=/dev/null, GIT_CONFIG_NOSYSTEM=1, -c core.hooksPath=/dev/null, and -c alias.<verb>= for the verb being run. Do not use repo-local aliases or hooks.

Start in token_meter/services/git_delivery.py at _subprocess_runner and _run_git, then trace how token_meter/app.py supplies paths through git_delivery_candidates. Ensure Git invocations ignore local and system configuration, aliases, and hooks while preserving current callers, and check the existing delivery behavior for regressions.