Memnox in your session

After memnox setup, you work in your agent, and Memnox is there with you. The agent is told where the boundary is when a session starts, it is reminded of a decision somebody already took at the moment it runs into one, and it can ask Memnox about the session with tools of its own. When Memnox needs a person, the question arrives in the agent's own prompt. The terminal is left for the few things a person does on purpose, which are listed at the end.

Memnox knows this session. Memnox Cloud knows everything around it. This page is the first half, and all of it works with no account and no network. What the rest of the team decided reaches the session through the same rule files once the machine is connected to a workspace.

Everything here is read from the rule files on disk. Nothing calls a network and nothing consults a model, so what the agent is told is the same thing the gate enforces.

What the agent is told when a session starts

The hook setup installed adds a short block to the agent's context as the session opens. It says, in this order:

Here it is on a machine memnox setup has just wired, with the baseline rules and the mode still at observe. The text is the runtime's own, and the one repository path is an example:

Memnox: Memnox is watching this session in observe mode: nothing is stopped, and what it would have asked about or refused is recorded.
Never run here: filesystem.read on **/.ssh, **/.ssh/** (you chose to deny this: almost no task needs the key itself, and a leaked one is somebody’s weekend); git.push-force or git.push-f or git.reset-hard or git.branch-d or git.clean-fd or git.reset or git.clean (you chose to deny this: it rewr....
A person is asked first: filesystem.delete (you chose to be asked about this: sometimes it really is the build directory, so a person should look); mcp.* (you chose to be asked about this: these are the calls whose consequences other people see); http.request (you chose to be asked about this: denying every unknown host breaks ordinary work on the first package install).
Project boundary: /Users/you/code/shop. A write outside it asks first.
When Memnox asks, the prompt puts the question to the person, who can say yes once or always; a refusal names what to use instead.

The block is paid for in the agent's context on every turn, so it is kept short on purpose. A long rule is clipped, only the first few rules of each kind are named and the rest are counted, and when a repository has more rules than fit, the mode and how to answer are the lines kept first. A rule set to observe on its own decides nothing, so it is not named. The block is made of rule names and reasons only, so no secret can be in it. In off mode nothing is said at all.

A stopped machine says it is stopped

When somebody has run memnox stop, the session opens on that instead of the boundary, so neither the agent nor its person assumes something is being checked:

Memnox: protection on this machine is stopped until 2026-09-24T16:00:00.000Z by sam (rotating the deploy key), so nothing is checked. "memnox start" turns it back on.

The time, the name and the reason are this example's; the line carries whatever the stop recorded.

A decision already taken, said where the agent meets it

Most of what an agent needs to know was decided once, by somebody, and is forgotten by the next session. Memnox says it again at the moment it applies, rather than all of it up front:

• When a prompt names it. A prompt that mentions a path a rule covers, or spells out an action such as git push that a rule is about, gets that decision added beside it.
• When a call meets it. Before a tool call a rule matched and let through, the decision behind that rule rides along with it. A refusal or a question already carries its own reason, so this is only ever said beside an allow.

At most two decisions are added at once, and each one is said once per session, so an agent working in the same file all afternoon is told once. A rule that matches every action decides nothing in particular and is never said. A prompt asking the agent to tidy up .env on the machine above gets:

A previous decision covers .env: it is never run, because you chose to deny this: almost no task needs the key itself, and a leaked one is somebody’s weekend (decided on this machine).

The last words say where the decision was taken: your team's published rules for rules a workspace published, whose reason already names who decided, decided on this machine for this machine's own rules, dated where memnox protect kept the date, and this repository's rules for the rule file checked into the repository.

Which agents hear it

Each agent's hooks can carry a different amount back into the conversation, so what Memnox can say depends on the agent:

An agent that hears none of this is still ruled at every other seam it passes through. The runtime and its seams has what each seam holds and what it cannot see.

How a person answers inside the session

In enforce, a rule that asks puts its question through the agent's own permission prompt, which is where its person already is. There is no second window and no command to switch to: Claude Code shows the prompt, the person says yes once or always, or says no.

A yes given there is learned. Memnox keeps the question by the call it was about. When that call then runs, the person said yes, so it is written to the record as a row naming the person, saying they answered in the agent's own prompt, and noticing learns it, so the same new thing is not asked about again. A call nobody allowed never runs, so it leaves nothing to learn from.

An agent whose hook cannot ask refuses instead, with the rule's reason and what to use instead, so the agent can take the other route rather than abandon the task. That is Codex, Gemini CLI and Windsurf, and Claude Code running with permissions bypassed. Cursor asks for commands and MCP calls in its own prompt, and its yes is not learned, because its later payload does not say which call it was. A call held for somebody who is not at the machine is a different path, and Approvals and delegation has it.

What the agent can ask Memnox

Setup adds an MCP server named memnox-session to every agent that is installed and reads MCP servers from a file: Claude Code, Codex, Cursor, Gemini CLI and Windsurf. It runs locally, launched by the agent, and gives the agent five tools:

So the person can ask the agent why was that stopped? or what did you do this session? and get Memnox's answer, from the record, in the conversation they are already having. A tool reads the session memnox run started when there is one, and otherwise the newest session of the agent that launched it, so one agent never reads another's by default. Every answer is clipped and capped, and anything shaped like a credential is masked, because the answer lands in a model's context.

The server is named memnox-session rather than memnox because memnox is the entry memnox agents onboard adds for a workspace, and two names mean neither command can remove the other's. memnox mcp wrap leaves it alone, since routing it through the proxy would put Memnox in front of itself.

Turning the tools off

memnox mcp session off   # take it out of every agent, and keep it out
memnox mcp session on    # put it back in every installed agent

Off is recorded, so the daemon does not put the server back on its next pass. After on, restart the agent so it starts the new server. memnox uninstall takes it out along with everything else.

What is left for the terminal

memnox --help lists only what a person types at a terminal, and says that everything else happens in the agent session:

memnox setup    # put this machine under Memnox, once
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
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 is still there and runs exactly as before: memnox help --all lists them, and the CLI reference has them all.