Spike: git hook security via policy gating

[schmitthub]

Context

Clawker has no general git hook security story — only one narrow, unconditional control: worktree containers mask the main repo's .git/hooks/ and .git/config read-only (opt-out gating tracked in #372). Everything else is unprotected:

• Bind mode (the default): the workspace's .git is the host's live .git. An agent can write .git/hooks/pre-commit, set core.hooksPath, core.fsmonitor, or filter.* in .git/config — and that code executes on the host the next time the user runs git in that checkout. Prompt injection → host code execution, with no gate, no audit, no signal.
• In-container execution: hooks that ship with the repo (or that the agent writes) run inside the container whenever the agent commits. That's inside the sandbox, but it executes with the agent's credentials (forwarded SSH/GPG agents, gh auth) and network grants.

The threat class is the same one that motivated the worktree masks; bind mode just has a bigger blast radius and no control at all.

Feature (future)

A policy layer for git hook security — declared in config (security.git_hooks or similar), enforced by clawker, instead of today's all-or-nothing per-mode hardcoding. Sketch of the policy space:

• off — current bind-mode behavior, hooks untouched
• audit — hooks/config writable but changes are detected and surfaced (warn on container stop, CP event, diff against creation-time snapshot)
• pin — hooks present at container creation are allowlisted by content hash; new/modified hooks are flagged or blocked
• block — RO masks over .git/hooks + hook-relevant config (what worktree mode does today), generalized to bind mode

Granularity questions: per-project vs per-agent, hooks vs config keys (core.hooksPath, core.fsmonitor, filter.*, diff.*.command, etc.), and how #372's worktree gate folds into the same policy surface instead of remaining a separate switch.

Spike questions

1. Threat model inventory — enumerate every git config vector that yields host-side execution from a bind-mounted .git (hooks dir, core.hooksPath redirect, fsmonitor, filters/clean/smudge, diff/merge drivers, credential helpers, aliases, includeIf). Which are detectable, which are maskable, which are only auditable?
2. Bind-mode mechanics — can .git/hooks be masked RO in bind mode without breaking legitimate in-container hook use? (Clawker's own dev flow runs pre-commit in-container — a blanket mask breaks real workflows, which is exactly why this needs policy, not a hardcode.)
3. Snapshot/diff approach — feasibility of hashing hooks + sensitive config at container creation and diffing at stop/exec boundaries; where does enforcement live (CLI, clawkerd, CP)?
4. Policy schema — where it lives (clawker.yaml security.* vs settings.yaml), defaults per workspace mode, interaction with Policy-gate worktree git lockdown (RO .git/hooks + .git/config masks) #372.
5. Prior art — how other agent sandboxes / CI systems handle untrusted-writer git dirs.

Out of scope

• The worktree mask opt-out itself (Policy-gate worktree git lockdown (RO .git/hooks + .git/config masks) #372)
• Non-git host-execution vectors

References

• Policy-gate worktree git lockdown (RO .git/hooks + .git/config masks) #372 — policy gate for the existing worktree RO masks (subset of this surface)
• Worktree containers: root-owned scaffold dir breaks git safe.directory check (go -buildvcs, pre-commit) #361 — worktree scaffold ownership fallout (context on the mask mechanics)
• docs/worktrees.mdx — Worktree Caveats (documents today's only control)

🤖 Generated with Claude Code