The maintainer asked for this handoff on 2026-10-29: "can you handoff to a new style session?" This session started from Claude Code on Oct 28, outside OCX, so nothing delivered the forum's posts to it. It missed a question in the ocx2 thread for three hours. Its successor is a run in the ocx2 thread, so it hears every post there.

Where things stand

• Branch agent-tools, tip 0fb01e7505. That check-in gives the live server, and hosts.json's default entry, --skin darkmode again. Agents had dropped the option twice, in August and September.
• Before it, 89362e0607:
  • migrate writes no systemd unit;
  • the documents name the maintainer's scripts serve, confine and receipt-reader, and their settings file hosts.json.

It is staged as release 89362e0607d5, and the live OCX page now runs it.

• The switch to serve: follow the wiki page "Transition runbook". The last state I know of:
  • fossil.service runs the maintainer's start-fossil.sh, which now runs /usr/local/libexec/ocx/serve directly.
  • At 5:57 PM EDT the extension root's ocx2-cgi was still the old direct link. The fix is ln -sfn /usr/local/libexec/ocx/confine /var/www/cgi-bin/ocx2-cgi.
  • The darkmode hosts.json still has to be installed in /usr/local/libexec/ocx/. Before restarting, stop the daemon and the receipt reader with the two pkill lines in the runbook's rollback step 2; restarting serve does not stop them.
  • I do not know whether migrate (step 6) has run, or whether the daemon has started. Ask the maintainer.
• Two sessions my stop list missed: mechanical-turk's run 79d2e85b2c, and cleave's run 18ec7f20e8. cleave's was started on Oct 9 by the older ocx2 run --session; if its stop does not take, kill -TERM its ocx2 run process. They are not confirmed stopped.
• The swk-ai program's move (runbook step 2) is deferred by the maintainer: "I don't want to mess with the isolation of swk-ai quite yet until everything is running nice."
• One account: the server's user namespace maps only root. So no ocx account exists, and the sandboxes are what keep the programs apart. The runbook's step 7 checks that with nsenter.
• Each accept on the daemon's root ends the daemon, and serve starts it only once. Start it again with /usr/local/libexec/ocx/confine daemon.

Open with the maintainer, after the switch

• The console: "console is junk. It should end up looking more like swk-ai when we are done with it."
• Certificate renewal needs something outside confine.
• Agent homes are shared read-write by every run (swk-ai's finding).
• Phase 2 of the wiki page "Migration plan".

The full list is queue.md, in the attached tar.

How the maintainer works with agents

The tar's memory/ holds the previous session's notes in full, indexed by MEMORY.md. Read them all, and keep what still holds as your own notes. The ones that matter most:

• Replies: questions in one or two lines, answered yes or no; reports in three lines at most; details in Fossil. Times in US Eastern.
• scripts/: never change it without the maintainer's explicit approval on the record.
• Check-in messages: a title, then Intent, Expression, Review and Demonstrates paragraphs, each after a blank line. check-msg.py checks them. Commit with --no-verify-comment, for the Co-Authored-By line.
• Each check-in:
  • run the full gate once, niced: nice -n 19 ionice -c3 crystal run ci.cr, about 145 s of its 180 s limit;
  • have gemma4:31b review it through the local Ollama, with gemma-review.py;
  • verify every finding before acting on it.
• Releases: stage green check-ins with bin/ocx2 stage CHECKOUT --root ROOT. Accepting one is the maintainer's.
• The forum: reply in the ocx2 thread after each batch.

Attached: opus-ocx2-handoff.tar

• handoff/memory/: the previous session's notes;
• handoff/queue.md: the backlog;
• handoff/check-msg.py: the check-in message check (python3 check-msg.py MESSAGE-FILE, run from the checkout);
• handoff/gemma-review.py: the Gemma review (python3 gemma-review.py NAME INTENT-FILE DIFF-FILE).