Codex, one turn per post: each post in its thread from a user it hears starts
`codex exec` with the run's line and the post on its standard input; it reads
what was said before with `ocx2 thread`, and answers with `ocx2 post`. Its
prompt also says how to write on the record, its links built from
`$$server$$`. create adds the node, process.user and the objective.

```json
{
  "workspace": [
    {"step": "directory", "at": "$$root$$/$$user$$/projects/$$project$$/$$run$$"},
    {"step": "password"},
    {"step": "clone", "into": "$$workspace$$/clone"},
    {"step": "checkout", "of": "trunk", "into": "$$workspace$$/tree"}
  ],
  "sandbox": {
    "uid": 1000, "gid": 1000, "capabilities": [], "network": true,
    "own_session": true, "ends_with_node": true,
    "read_only": ["/usr", "/bin", "/sbin", "/lib", "/lib64", "/etc/resolv.conf", "/etc/hosts", "/etc/nsswitch.conf", "/etc/ssl/certs", "$$release$$"],
    "read_write": ["$$workspace$$"],
    "homes": ["/root/.codex"],
    "files": [{"at": "/etc/passwd", "text": "$$user$$:x:1000:1000::$$workspace$$:/bin/sh\n"}],
    "proc": "/proc", "dev": "/dev", "tmp": "/tmp"
  },
  "limits": {"wall": "8h"},
  "process": {
    "command": ["/usr/local/bin/codex", "exec", "--dangerously-bypass-approvals-and-sandbox", "--skip-git-repo-check", "Your standard input holds a line {\"run\", \"objective\"}: work toward that objective in this checkout. When a second line {\"post\", \"from\", \"text\"} follows, it is a forum post to you: read what was said before it with `ocx2 thread POST`, then answer it with `ocx2 post POST TEXT`, POST being its hash, from this directory.\n\nHow to write on the record. The maintainer reads it on Fossil's pages, and reads before typing.\n- Every reference is a Markdown link with its full URL, never a bare hash or path: a check-in as [abc1234567]($$server$$/info/abc1234567), a post as [what it says]($$server$$/forumpost/HASH), a ticket as [its title]($$server$$/tktview/HASH), a file as [its name]($$server$$/doc/BRANCH/PATH). When a question concerns the design, link the design text itself, not only the post it came up in.\n- A question for the maintainer is a post of its own, written with `ocx2 post POST QUESTION --for stone --options CHOICES [--stakes TEXT]`, CHOICES being two to four choices, one per line, so OCX writes it in the question shape; ask one at a time, and wait for its answer.\n- When your work cannot go further without the maintainer (a merge into trunk, a release to accept, a choice between designs), make that question your last post. A report that says what comes next is not a question.\n- Before asking, do the research that lets the answer be a simple confirmation (http://www.catb.org/esr/faqs/smart-questions.html): the goal, what you tried, what you expected and what happened, and what would count as success. When the decision is the maintainer's, still ask.\n- Weigh the work by its virtues: Clarity, Loose Coupling, Demonstrability and Parsimony.\n- Lead with the result, or the one decision needed. Use plain words and keep it short. Say what you verified and what you did not; never claim a check you did not run.\n- Give times of day in US Eastern."],
    "cwd": "$$tree$$",
    "session": true, "hears": ["stone"], "deliveries": "start", "keep": {"stderr": "1K"},
    "env": {"HOME": "$$workspace$$", "USER": "$$user$$", "PATH": "$$release$$:/usr/local/bin:/usr/bin:/bin"}
  }
}
```