Wire GitHub Tools Into Your Eve Agent in One File (With Approval Rules Built In)

Why Bother With a GitHub Extension for Your Agent?

Most agent setups start the same way: you bolt on a GitHub token, hardcode a few REST calls, and pray the agent doesn't comment on the wrong PR at 2 AM. It works — until it doesn't.

The @github-tools/eve-extension package flips that model. Instead of hand-rolling auth and permissions, you register a connector-backed extension that mints short-lived, scoped tokens at runtime. Every write tool ships with an approval gate by default. And the whole thing lives in one file under agent/extensions/.

If you've been meaning to tighten up how your agent touches production repos, this is the cleanest entry point available right now. For a deeper look at how teams are automating large-scale repo operations safely, the Spotify Honk dataset migration case study is worth a read — same philosophy, bigger blast radius.

What You Get Out of the Box

• Connector-backed auth: Pass a Vercel Connect connector ID and the extension mints short-lived, scoped GitHub tokens at runtime — no long-lived PATs sitting in your env file.
• Presets that scope the toolset: code-review, issue-triage, repo-explorer, ci-ops, and maintainer map to Connect scopes automatically. Tokens only carry the permissions the tools actually need.
• Approval rules that travel with the config: Every write tool requires approval by default. You can gate individual tools with always, once, or an input-dependent predicate.
• Namespaced and versioned: The filename sets the namespace, so tools show up in your agent as github__addPullRequestComment. Bump the package version to pick up new tools, and the config schema validates on import.

Step 1 — Install the Package

# Add the extension to your eve agent project
pnpm add @github-tools/eve-extension

Step 2 — Register It From a File in agent/extensions/

Create a file (any name — the filename becomes the namespace) inside agent/extensions/. For example, agent/extensions/github.ts:

// agent/extensions/github.ts
import githubExtension from '@github-tools/eve-extension'

export default githubExtension({
  // Reference a Vercel Connect connector you've already created
  connector: 'github/my-connector',

  // Scope the toolset down to just what this agent needs
  preset: 'code-review',

  // Gate write tools. Here: require approval for comments
  // outside your own org, but auto-approve internal ones.
  requireApproval: {
    addPullRequestComment: ({ toolInput }) =>
      toolInput?.owner !== 'vercel-labs',
  },
})

That's it. One file registers the entire code-review toolset, wired to a Connect connector, with an approval predicate that lets your own org slide through while flagging external comments for human review.

Step 3 — Verify the Tools Land in Your Agent

After restart, your agent exposes the tools under the github__ namespace. You should see entries like:

github__addPullRequestComment
github__listPullRequests
github__getFileContents
...

The namespace comes from the filename — rename the file to gh-tools.ts and the tools become gh-tools__addPullRequestComment. Keep it predictable so your prompts and downstream logic don't drift.

Approval Rule Cheatsheet

Defaults are conservative — write tools require approval unless you explicitly loosen them. Don't loosen them unless you have a reason.

Limitations and Gotchas

• You still need a Vercel Connect connector. The extension doesn't create one for you. If you skip this step, the agent will fail at token-minting time with a connector-not-found error.
• Presets are opinionated. code-review won't magically give you repo-explorer capabilities. If you need tools from multiple presets, register multiple extensions or check whether the preset you picked actually covers your use case.
• Predicates run client-side. The requireApproval predicate executes in your agent runtime, not on Vercel's side. Don't put secrets in the predicate closure — it's just config.
• Schema validation on import. If your config shape is wrong, the extension throws at import time. That's a feature, not a bug — but it means a typo in requireApproval can block your whole agent from booting.
• Namespace collisions. Two extension files with the same basename will collide. Keep filenames unique across agent/extensions/.

Where to Go Next

Once GitHub tools are wired in, the natural next step is tightening the inputs your agent operates on. If you're building anything user-facing on top of these tools — say, a demo flow that lets stakeholders click through a login → PR → review sequence — the ProtoPie login flow tutorial shows how to prototype that UX without writing any code.

TL;DR

• pnpm add @github-tools/eve-extension and drop one file into agent/extensions/.
• Use a Vercel Connect connector for short-lived, scoped GitHub tokens.
• Pick a preset (code-review, issue-triage, repo-explorer, ci-ops, maintainer) to scope permissions automatically.
• Gate write tools with always, once, or an input predicate — defaults are safe.
• Tools are namespaced by filename and versioned by package.

If you're already running eve agents against real repos, this is the lowest-friction way to add GitHub capability without inventing your own auth layer. Start with the code-review preset, keep the default approval rules, and only widen scope when you have a concrete reason.

Reference: Vercel changelog — GitHub tools eve extension