dots runs Claude Code unattended; Codex flags half its work

The setup is deliberately modest in scope. The author describes a loop in which dots decides the policy and writes requests, a watcher script (hub_runner.py) picks them up every 10 minutes and launches Claude Code unattended, Codex CLI audits the finished result, and the outcome is reported back into the dots conversation. The stated division of labor is that dots handles operations while a human keeps the boundaries, with parallelism, model choice, audit on/off, timeout, ordering, and pausing all set by dots through a policy file.

What the author emphasizes most is the friction that only shows up in a scheduled environment. dots cannot write outside its own working folder, so a fixed entry point receives nothing and the entry must be a glob. On Windows, a CLI installed through npm inside the Claude desktop app is isolated under a package path, so it works by hand but fails every time from Task Scheduler unless launched by full path. Two Windows-specific traps are noted as well: os.kill(pid, 0) does not work as a liveness check, and a scheduler may kill the child process along with the parent. The author's completion bar is correspondingly strict, requiring that a request placed by dots itself be picked up through the scheduler and audited, not just run manually.

The stakes here come down to whether the audit loop is genuinely doing work or just adding a step. The measured rejection count suggests a separate model is catching gaps the author's own agent missed, but one day and 21 tasks is a thin basis, which the author acknowledges. The outcome likely hinges on whether that pattern holds over more runs, and whether an official dots API or webhook arrives that would let the file-and-screen-scraping approach be replaced.