Your Agent gets Git.

Most agentic coding tools treat every shell command like a loaded weapon; if the agent executes git log and you get a permission prompt, try git status and you get a permission prompt, git diff HEAD~3---you guessed it---permission prompt.

This is insane. These commands are read-only. They cannot modify your repository. They cannot delete your files. They cannot force-push to main. And yet every agent framework on the market leaves you with the same 3 options:

  1. Babysit every command and manually approve every single time.
  2. Accept everything and pray the agent doesn't nuke your codebase.
  3. Manually set up acceptance rules for something like git log:*, git diff:*, etc.

So I built get: a drop-in replacement for git that knows the difference between looking and touching.

The Problem Is Architectural

Agent frameworks don't understand what commands do. To them, git log and git push --force are the same thing: an opaque string that gets passed to a shell. The only safe default is to ask permission for everything.

This creates two failure modes.

The obvious one is friction---you're clicking "approve" dozens of times per session on commands that could never have caused harm.

The less obvious one is worse: the permission prompt lies to you.

When an agent asks to run a command, it provides a natural language description of what the command does. That description is hallucinated. The agent is guessing. It might say "checking the current branch" when it's actually running git checkout -b some-new-branch. You're approving a summary that may have no relationship to reality.

NOTE: to be fair, modern models typically won't fall into such a grave hallucination, but it is possible and worth mitigating.

The Fix: Parse, Don't Guess

get solves both problems by forking git's argument parser and building a state machine on top of it. Every git command gets parsed into a structured representation before anything executes. From that parse, two things happen:

  1. Read/write classification.
    • The state machine categorizes every command as either read-only or mutating.
    • Read-only commands---log, status, diff, show, branch --list, remote -v---execute immediately with no prompt.
    • Mutating commands---commit, push, checkout -b, reset, clean---go through the permission path.
  2. Ground-truth explanations.
    • When a mutating command does need approval, the prompt doesn't show the agent's hallucinated description.
    • It shows what the command will actually do, derived from the parsed arguments.
    • If the agent runs git clean -fd, you don't see "cleaning up the workspace;" you see the exact list of files that will be deleted.
      • The parser already knows since it has the full semantic representation of the command.

Why Fork the Parser?

A reasonable question:

why not just maintain a list of read-only subcommands and call it a day?

Because git commands aren't cleanly read-only or mutating at the subcommand level. git stash is mutating. git stash list is read-only. git branch lists branches (read). git branch -d feature deletes one (mutate). The classification depends on the full argument vector, not just the subcommand. You could try to build a table of known flag combinations, but git has hundreds of flags across dozens of subcommands, and the interactions between them are non-trivial. The arg parser already encodes all of this information. Forking it gives us a complete, correct model of what any git invocation will do---for free. We cover everything in git's argument surface except alias resolution. Aliases are the one part that's genuinely unparseable without execution: they're user-defined, arbitrary, and can map to shell commands via !.

A Concrete Example

An agent is working on a feature branch and wants to check what files have changed relative to main:

get diff --name-only main..HEAD

The parser sees diff, --name-only, and a revision range. State machine says: read-only. The command executes instantly. No prompt. The agent gets its file list and moves on.

Later, the agent wants to clean up untracked build artifacts:

get clean -fd

The parser sees clean, -f (force), -d (directories). State machine says: mutating. But instead of showing the agent's description ("removing build artifacts"), get shows you:

get: this command will permanently delete:
  build/
  dist/
  .cache/temp_xxxxx
Allow? [y/N]

You're approving facts, not fiction.

Where This Fits

get is one piece of a larger system I'm building at Rethink around inference-time compute efficiency for agentic coding. The same principle---statically analyzing commands before execution to determine their effects---extends beyond git.

We can cleanly map this model of taking an argument parser, composing a state machine representation, and deciding the semantic meaning.

Conclusion

Your agent doesn't need permission to read a git log. It needs a tool that knows the difference.

get is distributed under a Modified-MIT license and is part of the Rethink Automatic Development Platform.