Git Access for Your Research Agent, Scoped to Exactly What It Needs

"Let the agent check out our analysis repo, run it, and commit the results back" sounds like a one-line requirement. It's actually two requirements pulling in opposite directions: the agent needs real git access to a real remote, and the sandbox it runs in should still have no general path to the open internet. Most sandboxes make you choose. boxkite treats git access as a separate, narrow grant instead.

The ask: checkout, run, commit back

A research team maintaining a shared, version-controlled analysis codebase wants an agent that can clone the repo, run the analysis reproducibly against current data, and push results — a new branch, an updated notebook, a commit with regenerated output — back to the same remote everyone else works from. That's a normal research workflow. It just happens to require git operations from inside a sandbox.

Why "just give the sandbox internet access" is the wrong default

The easy way to enable this is to open up general network egress for the session — at which point git works, but so does everything else: exfiltration, arbitrary outbound calls, anything else running in that pod gaining a path to the internet it didn't need. Widening the whole network boundary to satisfy one specific requirement is a bigger grant than the requirement actually calls for.

enable_git_tools=True: eight operations, nothing broader

boxkite's git tool set is opt-in and enumerable: enable_git_tools=True adds exactly git_clone, git_status, git_add, git_commit, git_push, git_pull, git_branch, and git_checkout— eight named operations, not a general network exception. The pod's network-dark default doesn't change just because these tools are enabled.

Self-hosting so the remote can be internal-only

Because boxkite is self-hostable, the network-policy exception that lets these tools reach a git remote can point at a host inside the team's own network — an internally-hosted git server — rather than requiring a route to the public internet at all. The scope of the exception is something the team defines on its own cluster, not a fixed allowlist a vendor maintains.

Running the analysis in the same isolated pod

Once the repo is checked out, the actual analysis runs through the same python_interpreter used elsewhere in boxkite — a persistent, kept-alive interpreter, so the agent can load data, run the pipeline, inspect intermediate results, and iterate, all inside the one session before committing back whatever changed.

boxkite-mcp: the same environment from your own Claude Code or Cursor

Individual researchers don't need a separate integration to get at this — the same tool surface, including the opt-in git tools, is available through boxkite-mcp's Streamable-HTTP MCP endpoint, so a researcher driving their own Claude Code or Cursor session reaches the identical sandboxed, git-connected environment the team has already scoped, rather than a separate one-off setup per person.