From install to a rule in force

Memnox comes in three parts, and you can stop after any of them.

The first runs entirely on your machine and needs no account. The second puts that machine under a workspace, so somebody who is not sitting at it can answer an agent and change what it may do. The third reads what your team already settled, in Slack or GitHub, and turns it into rules.

Each part is useful on its own. This page walks all three in the order they build on each other.

What you need

Part 1. Govern the agent on your machine

1. 1

   See what your agents can already reach

   bash

   npx memnox

   This is the whole product's first screen, and it is a reading of your own disk. It names the agents on this machine, the credential files each one can read, and what the authenticated CLIs could do with those credentials: push an image, merge a pull request, publish a package.

   It closes with the line that matters, how many of those capabilities can change something outside this laptop and how many of them a rule currently covers. On a fresh machine the second number is zero.

   Nothing is sent anywhere and no credential value is ever printed, so this is safe to run on a work laptop before you have decided anything.

2. 2

   Ask where one of them came from

   bash

   memnox explain gh

   explain answers where a capability came from and what governs it: the credential file behind it, the projects it reaches, and every verb the CLI can run split into read, write and destructive.

   You can also ask in words.

   bash

   memnox explain "can claude-code read ~/.ssh/id_ed25519"

   The answer separates what is technically possible from what your rules allow, which are different questions and usually have different answers.

3. 3

   Write your first rules

   bash

   memnox protect --for git
   memnox protect --for gh

   This writes memnox.policies.toml into the current directory, one rule set per tool, generated from that tool's own verb table. Destructive verbs are denied, verbs somebody else can see are set to ask, and reads are left alone.

   The important part is what it does not do. The CLI keeps working. Only reading its credential file is denied, so gh still merges pull requests while an agent can no longer copy the token out from under it.

   Run it for as many tools as you like. Each one adds to the file rather than replacing it.

4. 4

   Try a rule before it bites

   bash

   memnox policy test "git push --force origin main"
   memnox policy test "git status"

   policy test gives the verdict a command would get, without running it. A refusal names the rule, the reason and a way forward.

   This is the cheapest way to understand a rule you just wrote, and the right place to find out that one is broader than you meant.

5. 5

   Put the seams in place

   bash

   memnox protect --interceptors

   Rules decide nothing until something is in the path of the commands. This installs small wrappers into ~/.memnox/bin, which only take effect when that directory comes first on PATH.

   Nothing on your machine changes yet. memnox run sets that PATH for the agent it starts, and nothing else.

   memnox setup does this for you, with no account and no network, and memnox status then says whether the machine is protected. Running setup twice changes nothing.

6. 6

   Start your agent under it

   bash

   memnox run --task "fix the invoice rounding" -- claude

   This is the recommended way to launch an agent. It sets the environment the agent needs to be governed, opens a session so one piece of work reads as one story, and keeps your working tree first so there is a way back.

   --task is optional and worth writing. It is what everything later compares against when it asks whether the agent went somewhere it was not asked to go.

7. 7

   Read what it did

   bash

   memnox timeline --since 1h
   memnox why

   timeline is one line per action, in order, with the verdict it met.

   why takes the last thing that did not simply proceed and explains it: the rule, the file and line it came from, the reason, and what to do instead. It is the command to reach for when an agent tells you it was blocked and you want the other side of the story.

8. 8

   Answer it without stopping your work

   When a rule says ask, the agent stops and waits. You can answer from the same terminal, or from any other one.

   bash

   memnox approvals
   memnox approve <id>

   The agent carries on the moment you answer. memnox deny <id> refuses it, and the agent is told which of the two happened rather than being left to guess.

9. 9

   Undo a bad afternoon

   Before the first write of a session, Memnox keeps your working tree. If the agent makes a mess, one command puts it back.

   bash

   memnox rewind --list
   memnox rewind

   Only files move. No commit, no branch and no stash is touched, and the state you rewound away from is kept as its own milestone, so a rewind is itself undoable.

That is the whole of the local product. Everything above decides things on its own, with no account and no network.

Part 2. Put the machine under a workspace

A workspace is what lets somebody who is not at this keyboard answer an agent, see what every machine did, and change the rules once for all of them.

1. 1

   Connect the machine and put its agents to work

   bash

   memnox login
   memnox setup

   memnox login is the one deliberate step towards the cloud. Setup on its own protects the machine and sends nothing; run after login, it also names each agent in the workspace and puts it there. Local enforcement keeps working when the workspace is unreachable.

   A code appears in your terminal and a browser page asks you to approve the machine, naming it and the runtime version.

   Screenshot

   The device approval page, showing the machine name, the code and the runtime version

   One approval covers the machine. Every agent on it still gets its own credential, so revoking one does not silence the others.

   Nothing about what an agent may do changes here, and memnox agents offboard reverses it.

   On a server with no browser, memnox login --no-open prints the code and the URL so you can approve it from your phone. --name chooses what the workspace calls this machine.

2. 2

   Check what it left running

   bash

   memnox daemon --status

   The daemon is what pulls your workspace's rules and carries a question up when an agent stops for a person. setup hands it to the machine so it starts at login; this says whether anything does. Without it the daemon runs only while a terminal is open, which is fine on a laptop and wrong on a server.

   Screenshot

   Console → Machines, with one machine listed, its rules version and its mode

3. 3

   Turn it from watching to stopping

   A new machine starts in observe, where every rule is matched and the verdict recorded but nothing is refused. When you have read a week of what it would have stopped:

   bash

   memnox config set mode enforce
   memnox doctor --wiring

   doctor --wiring is the answer to "is Memnox actually gating anything here", and every row that is not right carries the one command that fixes it.

   From watching it to letting it run is the longer version of this step, and worth reading before you flip it on a machine somebody else uses.

4. 4

   Answer an agent from anywhere

   Once a machine is under a workspace, an agent that stops for a person no longer needs that person at its terminal. The question travels up, and the answer comes back.

   Screenshot

   Console → Waiting on you, one held call with its three answers

   This is what makes an agent on a server answerable rather than only watched.

Part 3. Make rules out of what your team already settled

Your team has already decided most of this, in Slack threads and pull request reviews. This part reads those and proposes them as rules, so you are editing decisions rather than writing policy from nothing.

It reads only, and no agent acts through it.

1. 1

   Connect where your team decides things

   Slack, GitHub, Jira, Notion and the rest are connected once, from the console.

   Screenshot

   Console → Connectors, the catalogue with a system connected

2. 2

   Pick what it reads inside them

   Connecting a system is not the same as pointing at something in it. The second step is choosing the channels and repositories worth reading.

   Screenshot

   Console → Sources, step two, with one channel and one repository linked

   Start with one channel where decisions actually get made. More is not better here.

3. 3

   Let the evidence arrive

   History is walked in the background, bounded by what your plan keeps. Nothing waits for you to press anything, and the count on the console moves on its own.

4. 4

   Approve the first decision

   Memnox proposes what it read your team deciding, with the messages it came from attached.

   Screenshot

   Console → Waiting on you, one draft under Decisions to confirm with the evidence it was drawn from

   Every candidate carries its evidence, so rejecting one costs a glance. A draft governs nothing until somebody approves it, and a machine never promotes its own guess.

5. 5

   Put a rule set in force

   Approved decisions become a rule set, and a rule set reaches every machine within a minute of being published.

   Screenshot

   Console → Autonomy, a proposed rule set awaiting a second approval

   A second administrator approves before it publishes, where there is one. On a single seat, every escalation names you.

   bash

   memnox sync

   On any machine, that pulls the new rules immediately rather than waiting for the next heartbeat.

If you want it off

memnox daemon --uninstall
memnox uninstall

That removes the interceptors from PATH, restores every agent config from the backup taken when it was onboarded, and stops the machine starting the daemon. It tells you what it did rather than assuming, so read what it prints.

Where to go next