grith Supervises Coding Agents on Linux

grith-ai's grith is an open-source Linux supervisor for AI coding agents, written mainly in Rust and licensed under MPL-2.0 as of August 2026. It deals with a simple, awkward problem: an agent may look like it is editing code, then read secrets, spawn a process, or try to send data over the network. grith supervises at the syscall boundary, so the useful takeaway is that agentic coding safety can move below prompts, hooks, and tool permissions when the risk is OS-level. Syscall-level supervision is a policy check on the system calls a process asks the kernel to run before those calls execute.

Watch the kernel boundary, not only the agent

grith sits in front of the coding agent process and intercepts security-relevant Linux syscalls. Its README describes a scoring model: low-risk calls proceed, medium-risk calls are queued for human approval, and high-risk calls are denied before they run.

That is why developers noticed it. The project is not another prompt wrapper. It is trying to answer the moment where a coding agent leaves the polite world of tool descriptions and asks the operating system to do something real.

A concrete example makes the difference clear. Claude Code, Anthropic's coding agent, can be guided with project memory, hooks, slash commands, and permission choices. Those are useful boundaries. grith is a different boundary: it watches the process underneath and asks whether the attempted file read, shell command, network call, or process spawn should reach Linux at all.

The trap is assuming one boundary covers every failure mode. A hook can catch an intended tool call. It may not describe every effect of a child process, dependency script, or shell pipeline. Kernel-level supervision is interesting because it cares less about what the agent said and more about what the process actually tried to do.

Why the Hacker News crowd cared

The appeal is easy to understand if you have ever approved an agent command with a little knot in your stomach. The scary path is not usually the generated diff. It is the side effect: reading .env, running a postinstall script, curling a URL, or touching a path outside the repo.

grith's README uses exactly that kind of threat model: an agent ships a feature, then tries to POST an environment file to an outside host. The point is not that every agent will do this. The point is that a repo-level instruction cannot be the last line of defense for a process with filesystem, shell, and network access.

The project also ships built-in profiles for common coding agents, including Claude Code, Codex, Aider, Claude, Cline, Copilot, and Goose according to the repository README. The practical bet is that routine work should pass quietly, while strange work should stop and ask. That is the only version of supervision developers will tolerate for more than ten minutes.

The objection is real too. As of August 2026, the repository is small, with 4 GitHub stars and a recent push on August 26. It is Linux-only, and syscall supervision built on mechanisms such as ptrace and seccomp lives close to sharp edges. A tool at this layer needs boring correctness more than clever demos.

Put it beside Claude Code hooks, not instead of them

The clean mental model is two layers. Claude Code hooks describe expected agent behavior at the product boundary. grith describes allowed process behavior at the operating-system boundary.

For example, a repo might keep a small Claude Code hook boundary like this:

PreToolUse:
- Allow read-only inspection inside the repository.
- Ask before shell commands that modify files.
- Block commands that mention .env, SSH keys, or production credentials.

PostToolUse:
- Record changed paths and commands in the review note.
- Ask for a test run before a commit is proposed.

That is still worth having. It teaches the agent the shape of safe work and gives reviewers a useful receipt.

Now add grith underneath when the host is valuable. If a generated command invokes a helper binary, starts a child process, or reaches for the network, grith can evaluate the actual syscall path. The hook is the declared intent. The syscall supervisor is the observed behavior.

This is also where Model Context Protocol, or MCP, should stay in its lane. An MCP permission note can say an issue tracker server is read-only, or that a database server cannot run writes. That protects an integration. It does not automatically protect the local Linux process from reading a secret file and sending it somewhere else.

Try it when the host is worth protecting

grith is most interesting for local and CI-like Linux environments where an agent has enough power to be useful and enough power to make you nervous. That includes monorepos with real secrets nearby, developer workstations with SSH credentials, and automated coding runs that execute tests, package managers, or build scripts.

It is overkill for a toy repo, a throwaway container with no credentials, or a read-only code browsing session. Supervision has a cost. If every other action lands in an approval queue, developers will either turn it off or approve blindly, which is worse.

A good first experiment is boring on purpose. Pick one non-production Linux machine, one small repository, and one agent command you already trust. Run the same task with and without supervision, then compare what the agent tried to read, execute, spawn, and connect to.

This is the more concrete edge of AI coding governance: not policy prose, but a visible boundary around risky actions. If you want the model-evaluation side of the same problem, compare it with Harden.run Beats GPT5.5-xhigh on Agent Guards. grith's story is lower in the stack.

Copy this first-run receipt

Use this as a light receipt for a safe grith experiment. Keep it in the pull request, issue, or local notes. The value is not ceremony. The value is being able to tell whether the supervisor caught anything surprising.

grith first-run receipt

Date:
Machine:
Linux architecture:
Repository:
Agent command wrapped:
Task given to the agent:

Expected safe behavior:
- Reads limited to:
- Writes limited to:
- Network expected: yes / no
- Process spawns expected:

Queued actions:
- Action:
  Reason it looked risky:
  Approved or denied:
  Why:

Denied actions:
- Action:
  File, command, host, or process involved:
  Did the task still succeed:

Review result:
- Diff reviewed: yes / no
- Tests run:
- Anything to add to hooks, CLAUDE.md, or repo docs:

The important line is the last one. If grith queues the same harmless action every time, teach your higher-level workflow about it. If it catches a real surprise, tighten the repo rule, hook, or permission note so the agent gets a clearer boundary next time.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Claude Code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “grith Supervises Coding Agents on Linux.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• grith — source
• Claude — Agent
• Model Context Protocol — specification
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.