Login
Backlog
Login

Ideas raised while working, kept here for the maintainer's review instead of taking the work off course. Nothing here is decided; an item is built only once the maintainer picks it, and then leaves this page.

Item Raised What to work through first
Live stream's tool name 2026-10-26: watch is the built node watcher, not server-sent events (USAGE.md, "See a run live") choose a name for the planned live stream; no CLI or MCP name is claimed
A gone watcher's sandbox in a session of its own runs on once its bubblewrap has ended 2026-10-23, HISTORY.md decision 124: a sandbox whose own_session is true and whose ends_with_node is false, its watcher gone and its bubblewrap outer process ended at its program's end or wall before its next watcher takes the free run lock, leads a session nothing the old lock names leads to. The next watcher finds taken, ends what the old lock names and posts lost, but leaves this sandbox running (3 of 15 places tried, one under each timeout); a user holding R alone cannot send such a run name the sandbox's init and its start in the run's lock, as bubblewrap's --info-fd gives them, so the next watcher taking the free lock ends it along with the process launched
The next watcher can end a group or session that took one of an old run's lock numbers 2026-10-23, the adversarial review of e06e736748 and HISTORY.md decision 124: once nothing a run left is in a group or session numbered as its launched process or watcher was, Linux may give that number to a new process. The next watcher takes the run's free lock, finds taken, ends what the old lock names and posts lost; that can end the new process's group or session if its members started since the run's process. Within one boot this needs Linux to go round every free number, up to 4,194,304 on the server's host; another boot never matches the lock a run's leader outliving its terminal's hang-up and holding what the run leaves until its session is empty, so the next watcher taking the free lock finds those processes from a process that still holds them, never by a number that could be reused
An upstream's URL holding a token shows on git clone's command line while the clone runs 2026-10-23, the adversarial review of the import of large upstreams (HISTORY.md decision 120): ps showed the upstream's URL on the sandboxed git clone for the whole clone, so the detached import's job.json, its owner's alone, keeps a token from the host's other accounts only until the clone starts whether git should read the URL from a file in the import's directory, as fossil clone --args - reads a clone's (Fossil::Place#clone), or from a credential helper
An imported repository with a long history reads an old check-in in minutes 2026-10-22, the proof of HISTORY.md decision 120: beagleboard-org imported whole, 527,641 check-ins in a 10.6 GB repository, each manifest whole, 10,779 files for one of November 2018 (docs/fossil-git.md); fossil artifact read that one in 5 min 20 s, the tip's in 16 ms, so its timeline and diffs of old check-ins on the web would be as slow, while what follows the tip, check-ins and their export, is not whether the import should rebuild the new repository's deltas, or leave its history as Fossil's import writes it; and whether an upstream of such history should come in as a shorter history
A write on the server's repository can lose its run to writers outside OCX starting between OCX's wait and its next run 2026-10-23, the adversarial review of 3c4c65c090 (HISTORY.md decision 113): OCX's wait for a writer or a reader to let go, fossil sql running BEGIN EXCLUSIVE; ROLLBACK; (HISTORY.md decision 114), gives the lock back before the write runs again, and a writer starting in that moment, about 10 ms in the review's trial, takes it first. A run again after a wait that ended as a writer let go now counts against a cap of eight (Fossil::RERUNS), so a run is lost only if writers start in that moment before each of eight runs, another write's wait of OCX's among them, or hold the repository on past three waits of 15 s; Fossil 2.27 has no write from its command line that waits for the lock and keeps it (docs/fossil.md, "Forum posts") a write path that starts with BEGIN IMMEDIATE, for remaining tool writes on the repository; watcher reports now use Fossil's pages, so this is no longer their write path; fossil test-xfer, that handler from the command line, crashed given a push
While OCX's commit runs again against a reader of Fossil's settings, the account's other fossil commands wait at their start 2026-10-23, the adversarial review of aa650c80c4 (HISTORY.md decision 117): with a reader holding the settings of OCX's home 60 s, as a fossil sql session of the account in a read transaction does, while OCX added a file in a checkout and committed it, of 70 reads of the repository through fossil in that home, one a second, 42 failed (database is locked) after up to 30.03 s, 43 took over 15 s and 53 over 5 s; on 4228a3de0b, 44, 45 and 55. fossil commit writes the settings in its transaction, so each of its runs waits at its COMMIT for the reader, up to 15 s, keeping every new reader of the settings out, and every fossil command reads them as it starts (docs/fossil.md, "Forum posts"); OCX runs the commit again after each, as after a wait that went through (HISTORY.md decision 116) what fossil commit writes in the settings; whether OCX's commit can run where no other command of the account holds the settings, or stop running again once a run met a reader of them
A stop that comes as a run's sandbox starts can leave its program running until it ends of itself 2026-10-21, making the gate's specs faster: spec/ocx/watcher_spec.cr sent its stop once the run's lock named the launched program, which a poll now saw within 10 ms instead of 100 ms, and waited 30 s for sleep 30 in 2 of 3 tries: the TERM ended the bwrap the watcher launched, and the bwrap it had started, its parent gone, ran on with the program under init, holding the output pipes the watcher reads to their end. The specs now stop a program once it runs in its sandbox (spec/support/at_host.cr, AtHost.running?) whether bubblewrap's --die-with-parent leaves a window as it starts; then whether a stop should end the whole sandbox, not only the process launched, or the watcher end each sandbox init left to it
A directory step's remove_on still asks a sandbox whose ends_with_node is true 2026-10-22, HISTORY.md decision 118: the watcher now ends a sandbox's init, and every process of it with it, once the program has ended, whatever ends_with_node says, and removes a workspace only after; a watcher that has gone removes nothing. So the refusal of section 11, row 2, which says a process of the run could otherwise outlive the removal, may guard nothing now whether that refusal, and its note, should go or say another reason
Specs put the stand-in fossil first by redefining OCX::Fossil.env 2026-10-18, ef10d7e83b (spec/support/stand_in_fossil.cr): the specs then run an environment the program never builds; setting PATH instead is refused by precept C6's guard, rightly naming the fossil program as an explicit argument where a place is made, so a spec names the stand-in as it names a repository
Smaller echoes left by the adversarial fixes 2026-10-18, 720b6b5cf3 and 898527c82d: MCP's "no tool X" and "no method X" give a name that is not UTF-8 back as it came; a refused page form shows the value typed, a NUL included; find passes over every link, one inside the checkout too, and a link to an inside file not there yet is refused as one that "leads outside the checkout" each in plain words, or left as it is
A battery of how a reader gathers context, not only what it answers codex-cloud-2, 2026-10-18 (87ed3e00df): tell apart the objective, the current contract, the proposed change and the definitions it rests on; make what a document names reachable; run the same tasks with a context handed over and with a small start and tools to find the rest; score each claim and each unsupported invention, so qwen2.5-coder's 0 right of 51 is not read as understanding nothing which tasks, which documents a reader starts from, and how a claim is scored
A link to a tool whose input has name does not reach OCX's page 2026-10-16, cleave's Claude session: Fossil takes a name query parameter under /ext/ as the page's own path, so .../ocx2-cgi/node_user?name=x answered Fossil's 404; approve and collect, which replaced node_user and node_password (decision 76), take login. A form's POST, which carries name in its body, still works whether to rename name in every tool a link may name (secret, project, the wiki and unversioned tools), or have the page say so
A node and the server on different OCX releases fail obscurely cleave's Claude session, 2026-10-16: "a mismatch failed obscurely (Nil assertion failed when the server's receipt lacked rid)"; rid is optional now (src/ocx/commands/receipt.cr) whether the daemon compares its release with the server's status at setup, and refuses in plain words
The page answers a server set up wrong with 403, as it answers a refusal cleave's Claude session, 2026-10-16: "including a server started with a relative repository path" a distinct status and plain words for a setup error
Signs of life for each clone beyond the daemon's last round cleave's Claude session, 2026-10-16, and the maintainer's suggestion of a "listening" post at start; status now reads the daemon's last round from ROOT/state/daemon.log, even with no run, and shows local care with a clone and its project password file (USAGE.md, "Install or remove the hook") whether to show each clone's last round and pull time: the shared log's last line currently describes only the clone that ran last
A pattern from another repository on the same host, read there 2026-10-14, cleave's run using ollama's run/claude by URL a URL is fetched as it is, so any version of the page counts, not only one an admin or setup wrote; reading the other repository directly would keep that check
The test that sometimes fails in the gate's coverage run 2026-10-14, seen twice the gate now names it when it fails; fix it then
status shows what a session was last given the maintainer, 2026-10-14, on cleave: "seems we at least need status to report live process status. I cannot tell if anything is happening after my latest reply"; their reply was not given because the session's hears did not name them. status now lists each run that has not ended, whom a session hears, for every node user an administrator's run names, or local care with a clone and its project password file; why a post was not given is on the record, in the node's reply (HISTORY.md decision 79) whether to expose what each watcher last gave its session; the old hook log no longer exists
A session made by create hears the user who wrote it unless told otherwise 2026-10-14, cleave: run/claude heard stone, the maintainer posted as ec2-user, and their replies were not given whether a pattern's hears or the writer wins, and how the page shows who a session hears
stop, and every tool taking a run, takes any version of the run's post, an edit's hash included 2026-10-14, cleave: stop given the edit 57c73e54e3 answered "names no run"; the maintainer: "We need to think about some sane defaults." an edit holds no run of its own (protocol v1, section 3), so the tool resolves it to the first version
Bringing in a remote agent takes too many tries the maintainer, 2026-10-15, after a pattern page that did not read (CR LF, then a stray ]), a secret named $$secret. and a refused key, each found only after a create: "This process is such a pain." create checks a pattern's JSON and its secrets' names before it writes; secret tests a key it is given against what will use it, where one can; a run that ended on a fixable fault is run again without a new create; the forum thread a run writes is readable by the one who sent it
An agent handing a local model a subtask itself 2026-10-18, building the native agent (HISTORY.md decision 78): ocx_delegate was planned and trunk never had it; once a pattern such as run/gemma is written, a person can do it with create --to POST in the agent's thread, naming the pattern and a user of the model's own (not yet tried) a run an agent sends, with create from its run's clone (decision 81), takes no password step (decision 75), so the model could neither post nor save as its own user
A test ocx_test runs can read the clone's password 2026-10-18, a review of the native agent (HISTORY.md decision 78): a model may rewrite ocx-tests.json with ocx_edit, and ocx_test runs what it names in the run's workspace, which holds the clone and the password it remembers; the run needs network: true to reach Ollama, and the node's kept-log redaction removes only the secrets the run's env names, so the password can reach the endpoint and the kept standard output whether the tests run where the clone cannot be read, or every answer has the run user's password removed as the node removes a run's secrets
"remove_on": "saved" on the run/claude page's directory step 2026-10-19, 886487fcb2: saved a new term, then remove's one value; asked to approve it, the maintainer answered, 2026-10-22, "Maybe “remove_on”: “saved”", which HISTORY.md decision 103 takes; the page's edit to remove its workspace once saved waited for it the page's edit, which a user holding admin or setup saves
Starting a run on an event other than its arrival the maintainer, 2f2c0068cc (2026-10-07): "I think it is more a matter of when, which is immediately ("hook"), manually ("hand") or on some event" (KEEP.md); moved here from protocol v1's list of possible additions, 282599ff15 (2026-10-13) which events, and how a run names one as a key whose absence means what version 1 says now (protocol v1, section 15)
A shell in a run's sandbox beside its process the maintainer, 2f2c0068cc: "ocx2 run OCX-RECORD -- /bin/sh or ocx2 run OCX-RECORD --shell would be fine" (KEEP.md); terminal and attach were built instead (HISTORY.md decisions 82 and 83), so a person joins a terminal run's own process, and no tool starts a second process in a run's sandbox whether joining a run's terminal leaves any need for it
How a node says it runs nothing unconfined protocol v1's list of possible additions, 282599ff15 (2026-10-13): today it is the node's host, by the file ROOT/settings/unconfined (src/ocx/acting/view.cr), and a run sent to a node that runs nothing unconfined is refused only on arrival (protocol v1, section 11, row 7) whether a node states it where a sender can read it before writing a run
A workspace step that runs a command of the run's choosing protocol v1's list of possible additions, 282599ff15 (2026-10-13) what such a step may reach, and how its failure is reported, beside the step kinds of protocol v1, section 5
A filter on the kept logs, beyond their sizes protocol v1's list of possible additions, 282599ff15 (2026-10-13) what a filter names, and whether the node's removal of a run's secrets is one
Claude, voice chats among them, reaching OCX as a claude.ai custom connector 2026-11-02, the maintainer's plan, Connecting the openbeagle MCP server to Claude: ideas into Fossil first, as tickets where actionable, then status out for morning chats ocx2 already answers MCP's Streamable HTTP (src/ocx/mcp_http.cr) and OpenAI's tunnel (src/ocx/mcp_tunnel.cr), so what is missing is: a public HTTPS path for it on the server, which runs no agent and serves CGI only; sign-in that claude.ai's connectors accept (OAuth), and how it maps to a Fossil login and its letters, since a tool answers for its caller; which tools a voice chat gets, results kept short; where an idea that is no ticket goes (wiki, tech-note); one connector for every repository, or one each

Questions left by removing server run-work