Skip to content

MCP tools for hooks: list, manage local hooks, run, read audit log (no trust granting) #153

Description

@liam-russell

Problem

Hooks are how a worktree becomes usable (copy .env, install deps, symlink caches — the presets from #98), but agents can't see or manage them. A planner setting up an orchestration flow (#134) can't ensure worker worktrees will be provisioned; an agent debugging a broken worktree can't check whether a post-create hook failed; and "set up this repo's dev-env hooks" is a perfect delegable task that currently requires clicking through the Hooks dialog.

Proposal

Add hook tools to the SproutGit MCP server (#99, injected into sessions via #145), mirroring the existing IPC surface (HOOK_CREATE/UPDATE/DELETE/TOGGLE, getEffectiveHooks):

  • Read: list effective hooks (local + repo merged, with source, trigger, enabled/trusted state); read the hook run audit log for a worktree — lets an agent diagnose "why is this worktree broken" directly.
  • Write (local hooks only): create / update / delete / toggle entries in .sproutgit/local-hooks.json, including dependsOn validation. Writing a hook is configuring future arbitrary command execution, so agent writes are gated by the per-workspace agent-permission setting (default: ask).
  • Run: trigger a hook run for a worktree (same path as the Run Hook dialog), with results returned to the agent.

Hard security boundary

  • No trust tool. Repo-hook trust (hooks-trust.ts, isHookTrusted) is never exposed over MCP — trusting a repo-shipped script must remain an explicit human decision, otherwise a hostile repo could prompt-inject an agent into trusting its own hooks.
  • Repo hooks (sproutgit.hooks.json) stay read-only through the app/MCP, as today — an agent that wants to change them edits the file in its worktree and commits, and the normal per-hash trust flow applies on the human side.

Same trust rules should carry over to playbooks (#152), which reuse this architecture.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Table stakes — expected of any polished Git GUIarea:featureNew functionalityenhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions