Codex swept my whole disk for credentials. grith froze every real one. | grith

grith is launching soon<br>A security proxy for AI coding agents, enforced at the OS level. Register your interest to be notified when we go live.

esc to close<br>Codex, tasked with a DNS bug in grith, reaching into the secrets file of a completely unrelated personal project. Score 5.8, queued and never read. Real screenshot from the session - the project name is redacted.<br>Codex was supposed to be reading grith's own source code. It was working through a networking bug - DNS inspection, syscall coverage, nothing that goes anywhere near your home directory.<br>Then the approval prompts started. Not one or two. A steady stream of them, for files in projects that had nothing to do with the task. ~/.aws. ~/.ssh. ~/.gnupg. A crypto side-project's secrets directory. A client web app's OAuth library.<br>The agent had quietly started walking the entire disk looking for credentials. This is the trace.

The setup

We were running Codex under grith's supervisor on Linux:

grith exec codex

Codex itself was launched the way a lot of people run it - with its own guardrails off:

codex --dangerously-bypass-approvals-and-sandbox

That flag turns off Codex's built-in approval and sandbox layer. It is the exact configuration grith's supervisor mode exists to sit underneath: when the agent's own controls are disabled, grith is the boundary. Every process spawn, file read, and network connect the agent makes is intercepted at the syscall level and scored before the kernel is allowed to act on it.

The task was mundane. Codex was researching grith's DNS handling: running nl over events.rs and mod.rs, searching the codebase for socket-tracker symbols, reading the DNS inspection design docs, doing a couple of web searches about AF_PACKET and seccomp. Ordinary work on a specific bug in one repository.

None of that requires reading a single file outside the repo.

What we saw

grith started raising PERMISSION REQUIRED dialogs for paths that had nothing to do with DNS, or with grith, or with each other:

FileRead(/home/dan/.gnupg/private-keys-v1.d) score 8.0 CRITICAL<br>FileRead(/home/dan/.aws/cli) score 8.0 CRITICAL<br>FileRead(/home/dan/.aws/login) score 8.0 CRITICAL<br>FileRead(/home/dan/.ssh/keys) score 4.0<br>FileRead(/usr/lib/.../ansible_collections/.../credentials.yml)<br>FileRead(/home/dan/projects/.../a-different-project/secrets)

The strange part was the spread. These were not files in the working tree. They were credential stores scattered across the whole machine, and some of them belonged to completely unrelated projects - the header screenshot above is Codex reaching into the secrets file of a personal project it had never been pointed at. Why would an agent researching a DNS bug do that?

grith records every evaluation it makes to a local audit log, so we did not have to guess.

Following the trail

The audit database (~/.local/share/grith/audit/audit.db) holds one row per intercepted syscall: timestamp, the process that made it, the operation, the composite score, and grith's decision. Filtering to the Codex session made the shape obvious immediately.

Two things were at work. One was Codex itself, doing its normal work - SQLite scratch files, the occasional network listener, nl on source files. The other was a separate line of execution inside Codex's own process tree - as we'll show later, code running in Codex's in-process execution engine, not an external tool like find or rg that it launched. Under its own PID in the tree it did exactly one thing for four and a half minutes straight:

13:13:08 reads begin<br>13:13:08 FileRead / DirList ~/.cache/git/credential<br>13:13:14 FileRead / DirList ~/.docker<br>13:13:18 FileRead ~/.gnupg/private-keys-v1.d<br>13:14:58 FileRead ~/.aws/cli<br>13:15:04 FileRead ~/.aws/login<br>13:15:13 FileRead ~/.ssh/keys<br>...<br>13:17:43 reads stop

2,090 file and directory operations. Nothing else - no compilation, no network, no writes. Just reading, across /home/dan and /usr/lib, far outside the repository Codex was supposed to be working in.

The smoking gun

Here is the detail that turned "odd" into "look at this."

grith only logged operations that tripped one of its filters. So we pulled every distinct directory it touched - 707 of them - and checked them against a single question: how many contained a secret-shaped word in the path?

All of them. Every single one. credential, secret, token, private-keys, .aws, .gnupg, .docker, .ssh. Not one benign directory in the set.

A process that happened to be doing an innocent recursive listing would have produced thousands of ordinary paths - source files, configs, images. This process only surfaced at paths that look like they hold secrets. Whether it was a deliberately secret-targeted search or a broad filesystem walk where only the sensitive hits rose above grith's noise floor, the effect on disk was identical: a sweep of every credential store on the machine, reaching well outside the task's...