Recover and decide ahead

Four commands that change how people actually behave, for the same reason: each moves the question to a moment when answering it costs nothing. rewind after, replay and trace when the agent's own account of what happened is not enough, and check before.

Rewind

An agent runs unsupervised for three hours. It writes a broken migration, reformats forty files nobody asked about, and deletes a directory it misread as generated. None of it is committed, so git checkout . throws the good away with the bad, and there is no commit to go back to.

memnox rewind

Working tree back to mst_mtnxybca94e3, taken 2026-09-05T05:27:28.234Z.
 
  What it replaced is kept as mst_mtnxybg19f65.
  memnox rewind --to mst_mtnxybg19f65   undoes this
Only files moved. No commit, no branch and no stash was touched.

What it touches, and what it refuses to

A milestone is a tree object written under refs/memnox/, where nothing else looks. Never a commit, never a branch, never the stash, because this has to be invisible to everything you do with git afterwards or the cure is worse than the mess.

Where milestones come from

memnox run takes one before the agent's first command, so the way back is already there when you realise you need it. --no-milestone opts out, and memnox rewind --take makes one by hand.

An agent started without memnox run is covered too. The hook setup installed keeps a milestone before a session's first write in a repository, and the shell seams keep one before a command that destroys work: rm, rm -r, git reset --hard, git clean, git checkout -- ., git restore . and a mv of three or more paths. The first write is kept once per session and repository, and a destructive command at most once every twenty seconds per session. Only the newest twenty are kept in a repository. A milestone that cannot be kept is logged and never stops the agent.

The point is not the rollback. It is the willingness to let an agent run at all.

Rewind from the session

Mostly you will not type it. The agent's memnox-session server has a rewind tool, so the person can say put my files back to before this session in the conversation they are already having, and the agent asks Memnox. With nothing named it goes back to before the newest session first changed anything; the agent can also name a session or a milestone id from memnox rewind --list.

The agent can ask, and only the person can say yes:

The terminal command is still the way to list milestones, take one by hand or forget old ones, and the way back when the agent itself is what went wrong. See Memnox in your session for the other tools.

Replay

The timeline says what happened across every session. When one session went wrong, the question is narrower: what did it do, in order, and what came right before it failed.

From inside the session, the agent's replay tool gives a compact version of the same thing for the session it is in. At the terminal:

memnox replay            # the most recent session, which is also what --last means
memnox replay <session>  # one in particular
memnox replay --json     # the replay itself, for a script

Every action is listed with its surface, operation, target and verdict, and, while the machine was observing, what enforce would have said. Exit codes, circuit breaker trips and who resumed them, holds still waiting, and the milestones kept for the session are in the same column. The five actions right before a failure or a breaker trip are marked with > and carry their reasons and the id memnox trace opens.

It is read from the ledger, the pause records and the repositories the session kept milestones in, so it works long after every process involved has gone. A hold that was answered shows only where its row names who allowed it, because an answered hold is cleared from disk.

Resume

Some stops are on the session rather than the command: the circuit breaker pausing an agent that keeps failing the same way, or a session put under suspicion after a tool result read like instructions (see What changed under you).

memnox paused                      # what is held, and why
memnox resume <session> --by <you>

Resuming lifts either, and who lifted it stays in the record.

Check

The decision to let an agent run is made once, at the start, with nothing to go on. Half an hour later it reaches the one thing it should not have touched, and the choice is to abandon the run or approve under pressure. Under pressure the answer is yes.

memnox check "deploy the payments service"

read as: deploy · payments
 
  deny   railway.up            payments is frozen
  ask    gh.pr-merge           a merge is somebody's review
  allow  npm.test
 
  2 of 3 would stop, and nothing was run to find out.
  memnox freeze --lift   when the incident is over

Same engine, same rules, same state as the gate itself, run ahead of time with nothing executed. It exits non-zero when anything would stop, so it works in a script that runs before an agent does.

A phrase means more than one command until somebody says which. Answering about only the first would be a guess dressed as an answer, so it answers about all of them and shows its reading, which is how a wrong reading becomes visible rather than mysterious.

Trace

Afterwards, the timeline says the deploy ran and exited zero. It does not say what it printed, and the agent's own account of it is a summary written by something with an interest in the summary being good.

memnox trace evt_011179

  action    railway.delete
  agent     claude-code
  session   ses_9f21
  decision  deny
  reason    no volume deletes while payments is frozen
  rule      no-volume-deletes-while-frozen
  exit      1
  took      412 ms
  args      6197595503f01ee2

An id prefix is enough. args is a digest and never the arguments, because an argument list is exactly where a secret would be. When the session was started with memnox run --transcript, the tail of what it printed appears underneath, capped and bound by the same retention as everything else.