stop-that-shit Stops Agent Hashes

stop-that-shit is lennney’s MIT-licensed open-source Hook + Skill Guard for AI coding agents. It deals with a small but maddening failure mode: an agent is asked for one output file, then quietly adds an unrequested SHA-256 checksum, guard file, compatibility layer, or extra workflow. The takeaway is not that defensive work is always bad; it is that unrequested defensive work needs an executable boundary. For OpenAI Codex CLI users, it is a concrete agentic coding governance example that starts with one annoying hash and ends at scope control.

Start with the extra checksum

The project’s README opens with a familiar scene. You ask an agent to export one result file. It also generates a SHA-256 checksum that no later command reads.

That sounds tiny. It is also exactly the kind of tiny thing that makes agentic coding feel slippery.

stop-that-shit is a hook guard: a small enforcement layer that checks an agent action against an explicit task boundary before letting it pass. The repository describes support for Codex, Claude Code, Anthropic’s coding agent, OpenCode, and Hermes Agent CLI through adapters that share the same guard core.

As of August 2026, the repository shows 732 GitHub stars, is mainly JavaScript, uses the MIT license, and was last pushed on 2026-08-26. Its 0.1.0 release is framed as the first multi-platform version, with a shared Guard, Skill, paired cases, and a local runtime that stores metadata rather than a big pile of hidden project state.

The trap is to treat this as a war on checksums. It is not. The project is about whether the checksum was requested, used, or authorized by the current task.

Why developers cared about the Show HN

The Hacker News reaction made sense because the bug is not dramatic. It is ordinary.

Every individual agent move can sound reasonable. A checksum is careful. A guard is safe. A compatibility layer is helpful. A full test sweep is responsible.

Then the pull request arrives with more files, more process, and more review surface than the task needed.

That is why this project landed as more than a joke name. It gives a crisp label to benevolent scope creep: the agent is not malicious, but it is spending your repo’s complexity budget without asking.

The useful objection is also real. Sometimes the agent should do extra work. If a changed function has callers, it should inspect them. If an MCP server writes to a database, it may need an audit path. If a release artifact is supposed to be distributed, a checksum may be part of the job.

The line is not ‘never add safety.’ The line is ‘make the safety legible, requested, or tied to a downstream consumer.’ That is the same instinct behind good code review guardrails and the broader AI coding governance topic, just narrowed to something a hook can actually check.

How the guard thinks about permission

The README describes a simple pattern: write the task mode, such as review or change, then authorize limits around files, dependencies, hashes, and subagent budget. stop-that-shit checks those explicit boundaries on hook paths it covers.

That is more useful than an ever-growing AGENTS.md full of scolding. A repo rule like ‘do not over-engineer’ is emotionally satisfying but hard to execute. A boundary like ‘no new checksum files unless requested’ is machine-checkable.

A small Codex-flavored rule might look like this:

# AGENTS.md

When the task asks for one generated output, do not add checksum,
manifest, provenance, compatibility, or wrapper files unless the prompt
explicitly asks for them or a downstream command in this task consumes them.

If extra defensive work seems necessary, stop and ask before writing files.

That instruction is still useful. The stop-that-shit idea is that instructions alone are not enough when agents can write quickly and confidently.

The trap is to believe any hook guard is a full sandbox. The project itself is narrower: it checks explicit boundaries on covered hook paths. Agents can still read the repository, and they still need to handle real affected callers.

What a Codex user can borrow

You do not need to install a new guard to learn from this project. The immediate lesson is to separate durable repo rules from task-specific authority.

For Codex CLI work, the clean habit is to start a change with a short boundary receipt. What mode is this? Which files are in scope? Are new dependencies allowed? Are hashes or generated artifacts allowed? Can the agent call subagents or external MCP tools?

Here is a small handoff you can paste before a Codex session:

Task mode: change
Allowed files: src/export/report.ts, tests/export/report.test.ts
New dependencies: no
Generated artifacts: no checksums, no manifests, no extra report formats
MCP access: read-only docs lookup only
Verification: run the targeted test, then show git diff --stat
Stop condition: ask before adding files outside the allowed list

That is not bureaucracy. It is a cheap way to prevent the agent from inventing a second task.

The related MCP point matters. The Model Context Protocol is an integration standard for connecting agents to external systems such as tools, data, and services. Once a coding agent can touch an MCP server, the same boundary question moves from files to actions: is this server read-only for the current task, or can it write?

This is also where adjacent experiments like dmx MCP Server Adds Gated Agent Loops fit. The shared theme is not ‘trust nothing.’ It is ‘make the next agent step reviewable before it becomes repo state.’

Try stop-that-shit safely

Use a scratch branch and a boring repo first. You want to learn whether the guard catches your unwanted behavior without blocking normal repair work.

• Pick one repeated annoyance, such as unrequested checksum files or extra generated manifests.
• Add a narrow AGENTS.md rule that describes the boundary in plain language.
• Read the stop-that-shit install path for your agent host before changing hooks.
• Run one task that should be allowed, such as editing one test and one implementation file.
• Run one task that usually triggers the bad behavior, such as exporting a file where the agent likes to add SHA-256 output.
• Review git diff --stat before reading the whole diff.
• Keep the guard only if it reduces review noise without hiding necessary fixes.

It is a good fit when the same agent keeps adding unused artifacts, dependencies, wrapper layers, or broad verification steps. It is probably overkill when you are doing one-off exploration, security-sensitive release packaging where checksums are expected, or deep refactors where the affected surface is not known yet.

Common questions

• Does stop-that-shit stop every unnecessary agent action?

  No. It checks explicit boundaries on the hook paths and adapters the project covers. The README frames it around Codex, Claude Code, OpenCode, and Hermes Agent CLI, with limits such as files, dependencies, hashes, and subagent budget; it is not a universal sandbox for all possible agent behavior.

• Isn’t a checksum a good thing?

  Yes, when the task or release process needs one. The problem is an unrequested checksum that no later command reads and no reviewer asked for. In that case it adds repo state and review surface without reducing the actual work left to do.

• How is this different from adding more AGENTS.md rules?

  AGENTS.md is good for durable repo guidance, but long instruction files can become vague and self-contradictory. stop-that-shit’s stronger idea is to turn some boundaries into executable checks. Keep AGENTS.md short, then enforce the few rules that are concrete enough to test.

• Should I try it with Codex CLI first?

  Try it first where the failure is easy to reproduce. Codex CLI is a natural place if your workflow already uses scoped prompts, repo rules, and verification loops. Start with one behavior, such as ‘no unrequested hashes,’ and judge it by the diff it prevents, not by the elegance of the setup.

• What should I watch for in code review?

  Look for work that is plausible but disconnected from the request. New files, new dependencies, broad compatibility layers, and generated artifacts deserve a quick ‘who asked for this?’ check. If the answer is ‘nobody, and nothing consumes it,’ the guard is probably catching the right smell.

Best ways to use this research

• Best for: Codex users who already like agent help but dislike reviewing extra artifacts, wrapper code, and unexplained safety work.
• Best first artifact: A tiny boundary receipt before each agent run: mode, files, dependencies, generated outputs, MCP access, and verification command.
• Best comparison angle: Compare instruction-only repo rules with hook-enforced boundaries. If a rule can be checked mechanically, it probably should not live only as prose.
• Best limitation to remember: A guard can reduce scope creep, but it cannot decide product intent. The human still owns when extra safety work is actually part of the task.

Further reading

• stop-that-shit — source
• OpenAI Codex — docs
• Codex — Agent
• Model Context Protocol — specification

Next step

Pick one agent behavior that keeps making your diffs noisier. Write the boundary down, test it on a scratch branch, and only then decide whether a hook guard is worth keeping.

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.