Login
How ocx-console was set up
Login

Every step used to enable this project, in order, as the maintainer asked on 2026-11-04: "I want every step used to enable it to be documented in it's repository." Times are Detroit time. Each step says who did it and who should do it next time: a tool (OCX should do it, and doesn't yet), an agent, or a person. A step done by hand today is how we find what to automate.

The plan for the console itself is slice 1, on the ollama record: 0c6fb899eb.

Steps

  1. The repository was made. 2026-11-04, 11:18 AM, by the maintainer (ec2-user): the check-in "initial empty check-in" and the wiki pages run/claude and run/codex, all in the same second, which is what ocx2 project writes. The name was typed into the form on the OCX page, https://ollama.openbeagle.org/ollama/ext/ocx2-cgi/project, because a link can't carry it.

    • Next time: a person presses one link. Needs ticket 50be37bdb7: a tool's input called name can't be filled by a link, since Fossil reserves it under /ext/.

  2. x86-1 was asked to register its daemon here. 11:27 AM, by x86-1-session, on the ollama record (5bb9ee2315) and by message: ocx2 register https://ollama.openbeagle.org/ocx-console /var/lib/ocx/agents-daemon/settings/credentials/ocx-console.json --login x86-1, then the approve link, then register again to collect. The session that backs the console runs on that daemon, and its run names that clone's server-code.

    • A few minutes before 11:36 AM the maintainer ran that register at x86-1's own terminal, asking for goC4w, and x86-1 gave them the approve link it printed. x86-1 wrote these steps as posts 056e8a29aa and 298a2f8331 at 11:36 and 11:37 AM. At first they didn't reach the ollama server: x86-1 couldn't push there, and ocx2 post said ok anyway (ticket a3cf4ee8a7). Before 11:54 AM the maintainer gave x86-1 check-in (i) on ollama, and its next sync sent them; the server's receipts now name x86-1.
    • Next time: a tool should say when a push is refused, as that ticket asks.
    • Next time: a tool. project should give the approve link for a node on another machine, so no one has to ask that machine's session.

  3. An anonymous clone, to read. About 11:30 AM, by x86-1-session: fossil clone https://ollama.openbeagle.org/ocx-console. The repository lets anyone clone and read it.

    • Fossil printed the new clone's local admin password in its output. That password is only in the local file, not on the server; it was replaced at once with a random one, unprinted, and the file was later removed.
    • Next time: a tool. OCX's own clone step passes the URL on standard input and prints nothing.

  4. x86-1-session asked for a login. About 11:35 AM, by x86-1-session: ocx2 register https://ollama.openbeagle.org/ocx-console FILE --login x86-1-session --capabilities goi24p. FILE is the session's own, readable by its owner alone, outside every checkout. It printed an approve link.

    • Next time: an agent, as here.

  5. The maintainer approved the logins. Before 11:38 AM, by the maintainer, one press on each approve link: x86-1-session's, and, they said, x86-1's. approve makes the login with exactly the capabilities asked, never a, s, u or v, with a password no page shows.

    • Next time: a person. This is the one press that should stay a person's.

  6. x86-1-session collected its password and cloned. 11:38 AM, by x86-1-session: register again collected the password into FILE. The clone was made with the URL given to fossil --args - on standard input, with --save-http-password, so the password appeared on no command line and in no output. Then fossil open, and fossil sync, which signed in.

    • Next time: a tool. An agent outside a run has no OCX step that clones from FILE, so it had to build the URL itself. register should make the clone, as the daemon does for a node, or agents should come as runs.

  7. This file. By x86-1-session, its first check-in here.

  8. x86-1 collected its password, and its daemon cloned. 11:36 AM, by the maintainer at x86-1's terminal: register again, without --login, collected the password into settings/credentials/ocx-console.json. The running daemon made state/clones/ocx-console.fossil at 11:36 AM, with no restart, and its first round on it was at 11:36:40 AM. The clone's server-code is eedfb6655afc6f7c98cd94bd908c90402db2051a.

    • Next time: a tool, as step 2.

  9. The create link for the console's session. By x86-1-session, for the maintainer to press: login x86-1, clone eedfb6655a…, process user x86-1-ocx-console, a new thread "The OCX console session", and the session pattern patterns/session.md at sha3 3c16742c85….

    • The first link offered named session.md at 7a46415bae…, which names the old Codex pattern 6d7da18c…. That pattern runs /usr/local/bin/codex, which the client doesn't have, so every Codex task the session sent would exit 127. The current session.md names the fixed Codex pattern 0024f290….
    • Next time: a tool. create should name the current published session pattern itself, so no one has to find its hash.
    • That link went to the maintainer only in chat, in the middle of a long message, below several messages about x86-1's failed posts. It wasn't in this file, so the maintainer couldn't find it when they needed it. Next time: an agent puts a link a person must press at the top of its reply, labeled, and in this file.

  10. The maintainer pressed x86-1's create link. 11:55 AM, by the maintainer: run 2bb40ad3d5, to x86-1, clone eedfb6655a…, process user run-6b80e941, which create made up because the link named none. Its session.md is the old one, with Codex pattern 6d7da18c….

    • Next time: a person presses one link, and a tool fills in the current session pattern, as step 9 says.

  11. The session started. 11:57:43 AM, by x86-1's daemon: started in the run's thread, on its next round for this clone after 11:55, about 2 minutes later. x86-1 says its rounds reach each clone roughly every 7 minutes. Until it posted, nothing showed the run had been seen.

    • Next time: a tool. The daemon should be woken by the new run, or the page should say when it next looks.

  12. The session was told the current Codex pattern. 11:59 AM, by x86-1-session, a reply in the run's thread (e81d41693d): send Codex tasks with pattern 0024f290… and --clone, not the 6d7da18c… its pattern names. The server's receipt names x86-1-session as its sender.

    • Next time: nothing, once step 10's pattern is current.

  13. The session checked sign-in and the Referer, and asked how a press writes. By the session (run-6b80e941). It read the slice post and the Oct 31 prototype from ollama's public raw URLs, since it has no ollama login. It checked on a scratch Fossil server of its own, as the slice asks, and wrote CHECKS.md, committed at 12:02 PM. Then at about 12:03 PM it asked the maintainer a question in the run's thread: OCX takes a decision only from that project's own OCX page, so how should a press on the console write one?

    • Next time: an agent, as here. The session had no login to the ollama record it was asked to work from; the post and the prototype were readable only by knowing their raw URLs.

  14. The session made itself a browser. About 12:06 PM, by the session, as the maintainer asked at its terminal: "make yourself an alpine or debian file system for running a browser", from bootstrap-qcow2, "all your code in Crystal", and "save your setup scripts so your session can be reproducible". tools/browser-rootfs makes an Alpine root file system with Chromium, without root, and runs it; it opened the prototype served on the scratch server and its script ran.

    • Next time: a tool. A session's sandbox could offer a browser, or the session pattern could run this make before it starts.

  15. The session asked for a read-only login on swk-ai. 12:34 PM, by the session: the maintainer named swk-ai's design as one to start from, and swk-ai refuses an anonymous clone. ocx2 register https://ollama.openbeagle.org/swk-ai /workspace/swk-ai-credentials.json --login run-6b80e941 --capabilities gojr2 (clone, read files, wiki, tickets, forum; nothing that writes), and the approve link went to the maintainer at the terminal, as they asked.

    • The maintainer approved it at about 12:37 PM; register again collected the password, and swk-ai was cloned for reading, with the URL on standard input to fossil --args -, into a scratch directory.
    • Next time: an agent asks, a person presses.

  16. The console was installed on the server. Before 1:49 PM, by the maintainer, on the host where OCX built both machines' file systems: a copy of the static build (check-in e5fb4bd066, fossil sha3sum 11fc6f1de7…) from x86-1's file system, the run's tree/bin/console-static under /mnt/data/fossil/20261101/client, to the server's extension directory, /mnt/data/fossil/20261101/server/var/www/cgi-bin/console. Since then the server answers /ocx-console/ext/console, and the maintainer moved the conversation there: "Can we move to here now that this should be working?"

    • Next time: a tool. OCX's client-to-server release route (ticket 8986816c0b, x86-1-session's) is to carry a build from any client; the console's ci.cr has the two modes it asks of a project. Until it opens to other projects, a person copies.
    • Copied again by the maintainer at about 1:00 AM, Nov 5: check-in 2b2026f3ff (fossil sha3sum 02c3415f53…), with renaming and the fix for an old answer replacing the chosen conversation. The served page was checked to carry the fix.

  17. Posts reached the session minutes late: chat-timeline-user was never set. Found 2:18 PM by x86-1-session (28a87808dd), after the maintainer's posts of 2:10 and 2:12 PM reached the session only at about 2:13 PM. OCX's daemon is woken by a chat line Fossil adds for each new post, which it adds only when chat-timeline-user names someone. ocx2 project sets it only with --daemon-root, and this project was made without one, so the daemon pulled only when its chat poll timed out, about every 7 minutes (step 11). OCX's ticket be0de10a29.

    • To fix, a person with admin sets it to timeline: on the web at Admin, Chat, "Chat Timeline Robot Username", or fossil settings chat-timeline-user timeline on the server.
    • The maintainer set it at about 2:20 PM, to chat-robot, Fossil's own suggested name. The console leaves that login's lines out of its steps.
    • Next time: a tool. project should set it with or without --daemon-root, as the ticket asks.

  18. The maintainer gave themselves write-unversioned (y). About 2:37 PM, by the maintainer, to paste an image into the console: pasted images are stored as unversioned files (DESIGN.md, "Images"). The session had said they held it as admin; they didn't.

    • Next time: a person grants it, to whoever is to paste images; the console says so when it's missing.

  19. A WebAssembly toolchain. 2026-11-05, by this session, to check one Crystal back end can run in a phone app too (DESIGN.md, "One back end, two hosts"). This session's Crystal can't target wasm, so the work happens in the browser root: Alpine's Crystal, clang, wasm-ld, WASI's C library and iwasm, with SQLite, zlib and PCRE2 built for WASI from checked sources (about 40 seconds the first time).

    • Next time: a tool, crystal run tools/wasm/wasm.cr -- check REPOSITORY, after tools/browser-rootfs has made the root.

  20. Full-text search on x86-1's read clones. 2026-11-05, about 10:15 AM, by The One Place's session, approved by the maintainer (b518934b8f): "can this be done on just the client rootfs? x86-1 should be able to do it and i approve. i don't need the search on the web as much." Fossil's own search is turned on, indexed and stemmed (fts-config enable all, tokenizer porter, index on) in each of the 11 clones in /workspace/read, 14,071 documents in all. The server's search stays off.

    • Next time: a tool, crystal run tools/search.cr -- WORDS, which searches every clone and prints each hit with its link.

Still to do