Quickstart: govern an agent

One command, no account. At the end every agent on this machine runs inside a boundary that records every action and can stop the dangerous ones, and its working tree can be handed back if it makes a mess. A daemon keeps that boundary in place afterwards, so this is the only time you run it. From then on you work in your agent, and Memnox is in the session with you.

Put this machine under Memnox

npx memnox setup

Setup reads the machine first: the agents, the MCP servers, the authenticated CLIs and the credential files. It shows what they can reach today, before it asks anything, because whether to govern something that can read ~/.aws/credentials is a different decision from something that can only read this checkout. Then it asks once.

┌ memnox setup
│
◇ Looking for agents on this machine
│
◇ Found 3 agents
│ Claude Code, Cursor, Codex
│
◇ What they can reach today ╭──────────────────────────────
│   mcp         2 servers
│   can reach   ~/.ssh/id_ed25519, ~/.aws/credentials, ~/.config/gh/hosts.yml
│ ╰─────────────────────────────────────────────────────────
│
│   Put them under Memnox?  [Y/n] y
◇ Wired this machine
│ 12 interceptors, 5 rules, daemon installed, Claude Code, Codex, Cursor take a lease before writing, 2 MCP server(s) through the proxy, Claude Code, Codex, Cursor can ask Memnox from inside a session
│
└ This machine is under Memnox.
  Nothing left this machine: no account, no key, no network call.

The agents and paths above are an example; yours are read off your own disk. Saying yes wires the machine, all of it reversible:

It then asks whether to add the interceptors to your login PATH, so an editor started from the dock meets them too. It ends by pointing at memnox status, memnox config set mode enforce, memnox login and memnox uninstall.

See where it stands

memnox status

The mode, whether the daemon is keeping the machine, which agents are hooked, how many MCP servers go through Memnox, the rules in force, today's actions and how many were asked and denied, what is waiting for you, and whether a team is connected. Once setup has run, bare memnox shows the same screen. Every row is explained on What can already act on this machine.

Then work in your agent

Open your agent the way you always do. The hooks, the MCP proxy and the session tools live in its own configuration, so they are already in place. In Claude Code, Codex and Gemini CLI, the session opens with a short block saying the mode, what the rules here refuse and ask about, and the project boundary, and a decision somebody already took is said again where the agent meets it. When a rule asks, Claude Code puts the question in its own permission prompt, and a yes given there is learned. Ask the agent why was that stopped? and it asks Memnox. Memnox in your session has all of it, agent by agent.

That leaves the terminal for a handful of things a person does on purpose, and memnox --help lists only those:

memnox status   # where this machine stands
memnox rewind   # undo what an agent did to your files
memnox doctor   # check the wiring, and prove it holds
memnox stop     # turn protection off on purpose and on the record, e.g. --for 30m
memnox start    # turn it back on, in the mode it was stopped in
memnox update   # the latest version, with the wiring pointed at it
memnox login    # connect this machine to your team

Every other command on this page is still there: memnox help --all lists them.

To be sure for one run

The shell interceptors apply wherever ~/.memnox/bin comes first on PATH, which is what the login PATH question adds. To be sure for one run, and to get a session and a way back:

memnox run -- claude

That sets PATH so the wrappers are found first, SHELL so the agent's Bash tool goes through one, a session id so the work reads as one timeline, and it keeps a milestone of your working tree before anything runs.

The first run refuses nothing

The mode starts at observe: verdicts are recorded and nothing is denied. A rule you have not read yet must not wedge your agent on minute one, so memnox status counts what would have been asked and denied.

memnox timeline

claude-code  ses_9f21  2026-09-05
  14:03:24  deny   git.push-force origin main   rewriting published history is never automated
  14:03:19  allow  npm.test

Read a session of that. When the deny lines are all things you actually want stopped:

memnox config set mode enforce

The whole path, including what to do about the rules that turn out to be wrong, is in From watching it to letting it run.

When something is stopped

In the session, ask the agent why, and it calls Memnox's why tool. At the terminal:

memnox why            # the rule, the reason, the alternative and the evidence
memnox trace <id>     # that one action end to end

Either way, why reads back from the recorded row rather than re-evaluating, so the answer is what was decided at the time. Every deny names a way forward, and that is what an agent reads, which is why it takes the other route instead of abandoning the task.

Before it runs, and after it makes a mess

memnox check "deploy the payments service"   # decide before the loop starts
memnox rewind                                # the working tree, put back

check runs the same engine against the actions an intent resolves to, with nothing executed, and exits non-zero when anything would stop. rewind moves files and nothing else: no commit, no branch and no stash is touched. It is the one to know before you leave an agent running unsupervised, because it is the reason you can, and the agent can ask for it from the session, with your approval. Both are in full on Recover and decide ahead.

One piece at a time

Setup calls the commands that own each step, and each still runs on its own: memnox protect --yes for the baseline, memnox protect --interceptors for the wrappers, memnox mcp wrap for the proxy and memnox daemon --install for the daemon. From install to a rule in force walks them one at a time, and memnox doctor --wiring says whether each seam is actually in the path.

Undo all of it

memnox uninstall

Removes the wrappers, the hooks and the proxy wiring, puts every backup back, and stops the daemon keeping any of it. See the CLI reference for what --purge additionally deletes.