Codex notes

Codex runs every command an agent gives it inside a sandbox, and that sandbox has no network and can't write outside the project. A sandboxed parlo could neither record the thread in ~/.parlo nor let the colleague it starts reach its API. So parlo connect codex writes one rule, ~/.codex/rules/parlo.rules:

prefix_rule(pattern = ["parlo"], decision = "allow")

Codex then runs parlo, and only parlo, outside the sandbox without asking. parlo disconnect codex removes the rule.

Know what that allows: a Codex session you started read-only can still ask a colleague with --write, and that colleague changes files. parlo stops this for colleagues it started itself (a read-only colleague can only start read-only ones), but it can't see how you started your own Codex. Leave Codex unconnected if that matters to you.

For --worktree, parlo makes the worktree itself, in ~/.parlo/worktrees/<thread>, and runs Codex in it on every turn. A resumed Codex session works in the directory it is started from, so its own --worktree would not survive a follow-up. When you no longer need those worktrees, git worktree prune in your repository forgets the ones whose folders are gone.

A Codex shell command times out long before a colleague is done, so Codex uses parlo ask --detach and then parlo wait <thread> until the reply arrives. A detached colleague's steps go to ~/.parlo/logs/<thread>.log.

The rule matches only a command that starts with parlo. So in Codex the skill gives the message as one argument (parlo ask --detach claude -- '…') instead of a heredoc or a pipe: those would stay in the sandbox, where a heredoc can't even be created.