hardno-engine

hardno-engine in play

Inspiration

Coding agents can review and explain commands, but their permissions and logs usually change when you switch tools. I wanted the safety policy to belong to the developer and project and not to the agent.

What hardno-engine does

hardno is a local policy firewall for AI coding agents.

Running:

hardno wrap -- codex

places guarded command shims around Codex. If Codex attempts something dangerous, such as downloading content and piping it directly into a shell, hardno blocks that action, explains why, records a receipt, and lets Codex continue safely.

It includes:

Project, user, and built-in YAML policy layers
First-match rule evaluation
JSONL traces with a SQLite index
log, explain, and scoped allow commands
Deterministic prompt-injection heuristics
A dependency-free hook-protocol adapter

How I built it

hardno is a single static Go binary with one policy and trace core shared by two frontends: PATH shims and a JSON hook adapter.

I built it with Codex and GPT-5.6 during Build Week. Codex helped with architecture decisions, test-first implementation, debugging failure modes, CLI design, documentation, and release preparation.

Testing includes table-driven policy tests, scripted wrapped-shell sessions, golden JSON fixtures, race detection, and failure-mode tests.

Challenges and lessons

The hardest challenge was defining the enforcement boundary honestly. A PATH shim cannot observe everything, so hardno clearly documents what it can and cannot intercept.

I also made failure behavior intentional: hooks fail closed by requesting human review, while shell shims fail open so hardno cannot accidentally brick a developer’s terminal.

The biggest lesson was that observability and enforcement are different. Logs explain what happened; hardno creates a checkpoint before it happens.