cawdev-cli 1.0.4-beta → 1.0.6-beta

package/runner/README.md

@@ -101,8 +101,8 @@ with the window — there `q` stops it, and asks first when sessions are live.
 machine is configured, most changes are smaller than that. **Inside the
 terminal, press `c`** (or type `/config`): a picker over what this machine does
 — add a project, add a workspace, each agent with its current state ("Disable
-claude", "Enable agy"), the console-rules switch, and the config itself with the
-token cut short. Every row is one of the shell commands below, driven through
+claude", "Enable codex"), the console-rules switch, **Stop serving** each
+project, and the config itself with the token cut short. Every row is one of the shell commands below, driven through
 the terminal's own line editor and picker; `esc` anywhere in a step changes
 nothing. The screen edits the file the daemon says it booted from (the hello
 carries `configPath` since R288), so an older daemon is told to restart rather
@@ -126,7 +126,8 @@ is for scripts and for a machine with no daemon to attach to:
 cawdev config                          a menu, the same Select widget as everywhere else
 cawdev config add-project              serve one more project you can write to
 cawdev config add-workspace            another checkout for a project already served
-cawdev config agent enable|disable <claude|agy>
+cawdev config remove-project <slug>    stop serving a project; its checkouts stay on disk
+cawdev config agent enable|disable <claude|agy|codex>
 cawdev config rules on|off             accept permission rules from the console — R126
 cawdev config show                     this machine's config, token redacted
 ```
@@ -230,7 +231,8 @@ removes.
 `/logout` forgets it along with the session.
 
 **A paste stays one line.** Paste four hundred lines and the input shows
-`[pasted, 342 lines]`; all of it is sent. A paste that scrolled the transcript
+`[pasted, 342 lines]`; all of it is sent — into a prompt or into a command alike
+(`/new plan <paste>`, `/card <paste>`), its line breaks kept (`commandWords`). A paste that scrolled the transcript
 away would bury the thing this program exists to keep.
 
 Under `NO_COLOR` it is the same terminal without the colour: the picker still
@@ -331,6 +333,274 @@ browser anywhere and the terminal collects the session when you approve.
 error — it is what an expired session looks like, and the answer is the same as
 having none.
 
+### Advanced mode: one window per session
+
+`/advanced-mode` splits the terminal the way emacs does: **one window per
+session** this machine is running — or ran since you attached — above **the
+prompt, which stays at the bottom** the way a shell's does. Each window's title says what kind of
+session it is (`plan`, `dev`, `review`, `ask`…), where it stands, the card and
+the project, and its body is that session's output as it arrives. A frame's
+colour is its session's state — **red while it runs, green once it finished**
+(a plan planned, a dev developed), amber if it stopped any other way — and
+the focused window is drawn in heavy lines; `tab` and `shift+tab` move the focus, `1`–`9`
+jump to a window, and `enter` prompts the focused session exactly as it does
+outside the mode. `/advanced-mode` again (or `/advanced-mode off`) leaves.
+
+It is drawn on the terminal's **alternate screen**, like nano or emacs, and
+holds still the way they do: auto-wrap is off, so nothing ever scrolls the
+screen, and the wheel is sent to the program as arrow keys instead of sliding
+the terminal up. The normal screen and its scrollback are exactly as you left
+them — R81's reason
+for printing into the scrollback still holds, and this mode is something you
+ask for rather than the default. On the way out, what the watched session said
+meanwhile is laid into the scrollback, so nothing was lost by watching it here.
+
+**The PLANNED cards run across the top, grouped by project** — a line with
+each project's name over its cards and a rule between two projects, every
+project this machine serves included ("nothing planned" is an answer) — one
+small box each, titled with the card and its status — `R3 (Planned)` — the cards of
+every project this machine serves that are ready to be developed, read again
+every thirty seconds. **`d`** lists them and develops the one you pick, on this
+machine and on the card's own branch — except on a finished plan's window, where
+it is that plan's `/develop` (below) with no list; `/new dev` with nothing after it does the
+same anywhere, and `/new dev R3` goes straight to one. A full-width rule
+under the strip separates the board from the session windows; it comes out of
+the strip's own rows, never the windows'.
+
+**`/refresh`** reads the cards again now rather than on the next tick, and
+says what it found per project — `saasng: 5 considering · 2 planned · 1 in
+development` — and which project could not be read, and why. A project that
+cannot be read keeps its last cards and no other's: one unreadable slug used
+to leave every column of every project at 0, silently.
+
+**Four windows at most.** Past four, the rest are named on one line above the
+prompt — number, kind, state, card, in the state's colour — and `tab` (or the
+number) onto one brings it up in place of another. The focused session always
+has a window, then the ones still running, then the ended ones, each most
+recently looked at first.
+
+A window stays up when its session ends, and its last line says what can be
+done next:
+
+- **`d`** or **`/develop`** on a finished plan — the window says `d develops R2
+  here, in place of this plan` — starts the development of its card, on
+  this machine (the branch is the card's own). `/develop R30` names another
+  card, `@slug` its project, and `--codex`/`--claude`/`--agy` the agent —
+  otherwise the agent that PLANNED the card when its finished plan has a
+  window here, else `/agent`'s choice, exactly as `/new dev R30` does, because
+  it IS that command. Once the development has started the plan's window
+  closes, and the development's window takes its focus when this machine
+  takes the run; a start the platform refused leaves the plan's window up.
+- **`/pr`** on a finished session that wrote a branch opens its pull request
+  (`POST runs/{id}/pull-request` — through the card's work item, or from the
+  run itself for a session started from a sentence): this machine pushes the
+  branch if origin does not have it and runs `gh pr create` (so `gh` has to be
+  installed and signed in here). The POST answers with the workspace REQUEST,
+  and the terminal follows it (`GET /api/runners/{id}/workspace-requests/{id}`)
+  to its result: the URL — which the daemon confirms with `gh pr view` after
+  `gh pr create`, so "made" is the host's word and not gh's — or why there is
+  none, printed in full (no `gh` comes with its install line and the compare
+  link to open it by hand). It watched the run's `prUrl` before, which a
+  failure never writes, and said "asked for…" for as long as it was open.
+  A checkout cloned on demand is served like any other: the set of paths a
+  request may name is read per request, not taken at boot.
+- **`/continue`** on a failed or stopped session is the console's *Carry on*,
+  on this machine (`POST runs/{id}/carry-on` with this runner): the same run
+  re-queued, its window coming back to life when the daemon takes it. A
+  session that stopped BEFORE this terminal attached — the daemon forgets a
+  run as it ends, so after a restart nothing here knew of it — is found on
+  attach and on sign-in (`findStopped`: the first page of each served
+  project's runs, kept when `carriesOnHere` — yours, `canCarryOn`, and its
+  checkout on this machine or none), listed in the scrollback, and given a
+  window that opens on why it stopped.
+- **Finished, having built nothing** — a dev session that ended FINISHED
+  with no commit (IMPLEMENT stopped on a plan it would not follow, say) —
+  reads `finished · nothing built`, in amber rather than green, offers no
+  `/pr` but the re-plan instead, and its window shows its summary, where it
+  said why (`builtNothing`; the terminal reads the run's commits once it
+  ends, and claims nothing until it has).
+- **`/open`** opens the pull request in your browser. It reads the run again
+  first — the runner records the link after the run is FINISHED, so the copy
+  taken at that moment has none — and falls back to the card's work item.
+  On a finished PLAN, which opens no pull request, it opens the card on cawdev
+  instead — `roadmap/R2?show=plan` (`issues/…` for an issue) — with the plan
+  of record unfolded and scrolled to: that plan is what the session produced.
+- **`/drop`** deletes the checkout the session was cloned into, when it was one
+  made on demand (below): asked first, naming the path, and refused while a
+  run is in it or holds it, with uncommitted files, or with a commit origin
+  does not have. The checkouts in the config are never offered — a project
+  always keeps them.
+- **`/close`** takes the window away.
+
+**`/new`** starts a session from the prompt, aimed at this machine so its
+window opens here: `/new plan R3`, `/new dev R3`, `/new ask <question>` — or a
+task in words with no card: `/new plan add a CSV export of the invoices` writes
+its card first and plans it (R150), and `/new dev fix the sort on the client
+list` writes its card too (`cardTitleFor`: the sentence, cut between words
+near a hundred characters, the whole text in the body) and then develops it
+exactly as `/new dev R12` would — a number, a work item on the development
+board, a branch of its own, and the card session's instruction to commit. It
+was a manual session on a `task-…` branch with no card, which never reached
+the board and was never told to commit. A card reference on its own is that card; anything
+else is the task in words. **The project is always asked** — a list of what
+this machine serves — unless the command names it with `@project`, or
+advanced mode is narrowed to ONE project (`/projects`), which is a choice
+already made rather than a guess. Never guessed from the focused window, nor
+from a machine serving just one, since a session on the wrong project is a
+card planned or a branch cut in the wrong repository. `/new dev` alone and `d` list the planned cards of every project,
+each with its own, so they ask nothing more. A usage window over this machine's threshold is refused in a
+sentence; `--anyway` starts it regardless, the same decision the console's
+panel asks for. All four commands need you signed in (`/login`), and they work
+outside advanced mode too, on the session you are watching.
+
+**The prompt says which window it acts on.** In advanced mode the line at the
+bottom leads with the focused window's number — `[2] cawdev ▸ /pr`, `[2]
+enter prompts “…”` — and a command's answer keeps the number of the window it
+was about (`[2] A session on … is running`), so a note left on screen after
+the focus moved still says whose it was.
+
+**A project deleted in the console is not offered.** The config on this
+machine still names it, and nothing on the platform can change that file, so
+the terminal asks: a served project whose roadmap read answers 404 — deleted,
+or your access went — is left out of the picker, the strip, `/new` and `/card`,
+and one line says so, once, after the mode is on screen. `c` → **Stop serving
+ngsign** (`cawdev config remove-project ngsign`) takes it out of the config;
+the checkouts stay where they are, and the daemon stops polling for it at its
+next restart, because `projects` is read at boot.
+
+**Which projects it shows is yours to pick.** `/advanced-mode` on a machine
+serving several projects opens a picker with every one ticked — space (or a
+digit) ticks and unticks, `a` all or none, enter confirms — and only the
+projects ticked are drawn: their windows, their roadmap on top, and the ones
+`/new` asks between. `/advanced-mode @saasng @ngsign` names them and asks
+nothing; `/projects` asks again from inside the mode; `/reload` keeps the
+pick. A prompt never talks to a session of a project that is not shown.
+
+**↑ is history, as in a shell.** On a line nothing has been typed on yet —
+empty, or the bare `/` a command line opens with — ↑ and ↓ walk what was
+typed before (kept across launches, `history.mjs`); a command line walks only
+the commands. Once something is typed, the arrows move in the list of
+commands instead, and enter sends a recalled line as it is. Outside advanced
+mode ↑ with no line open recalls the last entry onto the line it belongs to;
+in advanced mode the wheel arrives as arrows, so there it is `/` or enter,
+then ↑.
+
+**`/view`** opens the focused session's page on cawdev — transcript, stages,
+card — in the browser, on the console this terminal signed in to.
+
+**`/view R29`** prints a card here instead: its status, section, tags, branch,
+work item and pull request, who is coding or reviewing it, what it is related
+to, its page on the web, and the first thirty lines of its body (`cardLines`,
+pure). `/view <words>` finds it by its title among the cards of the projects on
+screen and offers a list when several match; `@slug` names the project;
+**`/view card`** is the focused session's own card.
+
+**Which agent `/new` asks for.** `--claude`, `--codex` or `--agy` on a `/new`
+names that session's agent (`/new dev R12 --codex`); `/agent codex` makes it
+the terminal's choice for every `/new` after it, kept across launches
+(`prefs.mjs`, `~/.cawdev/terminal.json`) and shown in advanced mode's prompt
+title; `/agent default` hands the choice back to the project. A flag beats
+`/agent`, and with neither nothing is named — the project's default decides,
+as it always has. A name no runner spawns is refused, by `/agent` and by the
+platform alike, rather than spawned as Claude Code; `/agent codex` on a
+machine that does not list codex says so (`c` → Enable codex). The window's
+`Codex · GPT-5-codex` line says which one actually ran.
+
+**A stage asks rather than stops.** A decision that is the person's — a scope
+the card leaves open, a plan the code has moved away from — is asked with
+`ask_user`, and the stage carries on with the answer; PLAN asks before it
+writes, so a plan never hands IMPLEMENT an open question, and IMPLEMENT asks
+when its plan is wrong or incomplete instead of stopping (`ASK_DONT_STOP`).
+Codex is given the time to: cawdev's MCP server gets `tool_timeout_sec` 660 on
+its side, longer than `ask_user`'s ten-minute wait — Codex's own default of
+60 s cut every question off before anybody could answer it.
+
+**Codex and Antigravity write only on a machine that allows everything.**
+Neither has per-command permissions — Codex's sandbox is read-only, blocks the
+network (no push) or is off — so a session of theirs that writes is refused,
+unspawned, until the machine accepts console rules AND "Allow everything" is
+ticked on it. The refusal says so in steps, for this machine
+(`needsEverything`, lib/agents.mjs): which of the two is done, the Runners page
+on this console, the command to start it again — and it is written on the
+run's transcript as well as its summary, so the window shows it; a failed
+window prints its run's summary (`sayWhyItFailed`) rather than just "failed".
+
+**`/card <the idea in words>`** writes a card in **Considering** and starts
+nothing — no session, no branch, nothing spent: the roadmap's first column
+is where an idea waits to be decided on, and writing one down does not need
+a model. Titled by its words (`cardTitleFor`), the whole text in its body;
+the project chosen exactly as `/new` chooses it (`@project`, else advanced
+mode narrowed to one, else asked).
+
+**Across the top, the roadmap** (`roadmapStrip`): every project this machine
+serves as a small board — Considering, Planned and In development side by
+side, one line per card, `●` on a card with a session running now; Merged,
+Shipped and Declined — work that is over, and only grows — are counts beside
+the project's name (`1 merged · 2 shipped`), as the console's board folds its
+own last columns. As tall as the fullest column, never more than a
+third of the screen, and gone before the windows are on a short terminal.
+When the room runs out it is SAID: a column ends in `+N more`, empty columns
+go first when the width does, then whole columns (Considering, then Planned —
+In development stays longest), named in the header as `considering 3
+hidden`, then projects, counted as `+N projects`. Read every 30 s.
+
+**A window says which agent and which model** — `Claude · Opus 5.5`,
+`Codex · GPT-5-codex` — bold and underlined at the head of its second line
+(`agentModelFor`, `modelLabel`). A live session's is the daemon's word, what
+it actually spawned: the model asked for, replaced by the one Claude Code
+announces on `init`, and per STAGE on a walked run, since each stage is its
+own process. An ended one's is the platform's. No model named reads
+`default model` — the CLI's own choice — rather than a guess.
+
+**A window's project has a line of its own**, the second, under the title
+(`subtitleFor`) — at the end of the title a long card name pushed it out of
+sight. **A dev window adds where it is working**: the project and the absolute
+path of the checkout — on a machine with `saasng` and its `-auto-N` clones, the
+one directory to open. Cut from the left when narrow, so the end of the path
+survives.
+
+**The prompt shows what is open, not what was.** A question is the prompt's
+banner alone, whole and wrapped between words, and it goes the moment it is
+answered — here or in the console. A permission request's lines are tagged
+with it (`sayAbout`) and leave when it is decided.
+
+**A question says which window it came from.** With four sessions on screen,
+"waiting for an answer" is not enough to know whose. A question or a
+permission request names its session (`sessionTag`) — `2 · dev · R3 Client
+mail… — saasng`: the window's number, its kind, its card and its project — in
+the line announcing it, in the title of the picker that answers it, and above
+the banner. The card is cut to 32 columns so the question itself still fits.
+
+### Checkouts made on demand: `autoWorkspaces`
+
+`"autoWorkspaces": 3` in the machine's config lets the daemon CLONE up to three
+more checkouts of a project by itself, when a coding run would otherwise wait
+for "no free workspace" — so `/new dev R4` starts while R3 is still being
+developed. Absent or 0 is none, as it has always been. The clone sits beside
+the project's first checkout as `<first>-auto-2`, `-auto-3`…; it is a local
+clone of the first (no credential, no download) with `origin` put back to the
+project's remote. Nothing is written to the config: the daemon finds these by
+their name at boot and on SIGHUP, so deleting one — `/drop`, or by hand — is
+the whole of removing it. A clone and not a `git worktree`, on purpose: the
+daemon's reset checks the default branch out, which git refuses in a second
+worktree. Changed without a restart, like `agentCommands`.
+
+### `/reload`
+
+Quitting and starting again, in one word — for when the client's code changed
+on disk. The same command line runs again in a fresh process. When nothing is
+running here the runner is stopped first (as `q` does), so the relaunch starts
+it on the new code too; when sessions are live it is kept, and the terminal
+says so — restarting it would end them. Under `runner.mjs --attach` the runner
+is the terminal's own process, so `/reload` says to quit and start again.
+
+It comes back **as you left it**: advanced mode if it was on, the same window
+focused and the same session watched, the daemon's log shown or not, and the
+windows of sessions that had ended — with their `/develop` and `/pr` — except
+the ones you closed. The state travels to the new process in
+`CAWDEV_RELOAD_STATE`, which that process reads once and removes, so nothing it
+spawns inherits it.
+
 ### Where the socket is
 
 `~/.cawdev/run/<runner name>.sock`, in a `0700` directory, removed when the
@@ -370,6 +640,23 @@ How many coding runs go at once is `min(workspaces, maxSessions)`. A run that
 waits now says **"no free workspace in cawdev (2 here, all busy)"** instead of
 "that project already has a run here", which was a proxy for it.
 
+**A free checkout with uncommitted work in it is not preferred over a clean
+one** (R71/i258). A coding run with no pinned checkout and no free preferred
+one now takes the first free checkout whose tree reads clean, checking each
+free checkout in `workspaces` order until one does. It only falls back to a
+free checkout somebody stranded work in — and today's *Start anyway* flow —
+when every free checkout of that project is dirty; the log says so when it
+happens. A *preferred* checkout (R212) is still taken whether it is clean or
+not: it is the checkout the branch last ran in, so its uncommitted work is
+plausibly that branch's own.
+
+**Unless the run asked to wait for a clean one instead** (`waitForClean`,
+R270). Then a preferred checkout is taken only when it reads clean, and when
+nothing free reads clean the run is left queued — with a reason saying so —
+rather than falling back to the first free checkout regardless. See "Prepares
+the working copy" below for where that flag comes from and what the daemon
+says about knowing it.
+
 **This number caps coding and nothing else** (R70). `ASK`, `ROADMAP`, `AUDIT`
 and `SCOPE` runs take no workspace, so a project whose checkouts are all busy
 still starts a question, an entry-writing session, an audit and a scoping
@@ -599,7 +886,24 @@ files at all. R47 removes the need for this by giving each run a workspace.
    uncommitted before the run is started, and the decision arrives with the
    claim as `allowDirty`. Without it the runner still refuses, with the file
    list, and fails the run saying so: a run that arrives with no flag is one
-   nobody was warned about.
+   nobody was warned about. **Except when the dirt is the branch's own**: the
+   platform NAMED the checkout (a carried-on run's held workspace, R80, or a
+   pinned work item's next run, R86) and it is already on the run's branch.
+   Then the work is kept and not cleaned — refusing it made every *Carry on*
+   a second failure about work the run itself had written.
+
+   **Or the run may have said, before it got this far, to wait instead**
+   (`waitForClean`, R270) — the console's third way out of the dirty-checkout
+   panel, alongside *Start anyway* and *Cancel*. That is decided earlier, in
+   `pickWorkspace`, at poll time: with `waitForClean` set, the preferred
+   checkout is taken only when it reads clean, and when nothing free reads
+   clean the run is left queued with a reason rather than claimed at all — so
+   by the time a claim reaches this step, the checkout it names is already
+   clean and this whole paragraph does not apply. The daemon says
+   `waitForClean: true` in its capabilities, the same way it says
+   `baseBranches: true`, and an older daemon that does not is not offered such
+   a run — the platform tells it apart rather than letting it take a dirty
+   checkout the person explicitly asked it not to.
 
    With it, the edits are **carried onto the branch** — stashed, checked out,
    popped (R57). `git checkout` refuses outright when a locally modified file
@@ -659,6 +963,19 @@ files at all. R47 removes the need for this by giving each run a workspace.
    writes to git: no merging, no branch deletion, no pushing. (A project's own
    rules can ask for all three — see below — but that is a queued action with a
    name on it, not something the survey does in passing.)
+7b. **A stage is not done while its commands are still running.** A stage is
+   one turn, closed the moment the turn ends, so a test suite started with
+   `run_in_background` and never waited for is a result lost. The daemon
+   follows the session's background shells (`lib/background-shells.mjs`:
+   `Bash` with `run_in_background`, `BashOutput`, `KillShell`); a stage whose
+   turn ends with one still running, or finished and never read, is reported
+   FAILED with the commands named, and the run fails with it — keeping its
+   checkout and its session (R80), so **`/continue` picks it up**. Where it
+   resumes is the platform's (R263: the claim's lifecycle starts at the first
+   stage not DONE, with what the DONE ones said); what the daemon adds is WHY
+   the stage stopped — the re-run is handed that and told to run its commands
+   in the foreground. IMPLEMENT and TEST are also told up front to
+   wait for every command, and TEST to commit — no stage after it writes code.
 8. **Reports the lifecycle back** and, if the session dies without saying
    anything, ends the run rather than leaving it `RUNNING` forever.
 
@@ -729,12 +1046,34 @@ that reaches the server by another name than the platform does (a LAN
 hostname), and `timeoutSeconds` (600) bounding the scan and the wait.
 
 **Community Edition.** A server that refuses `sonar.branch.name` — every
-Community Edition — is *skipped by default*: the reading carries an error
-saying so, and nothing is analysed. `"whenBranchesRefused": "main"` in the
-block opts into the fallback, which analyses the branch as the project's
-**main** analysis and marks the reading `MAIN` with a warning. Understand what
-that trades: the project's own dashboard, and the platform's project reading
-with it, then describe whichever branch scanned last. Nothing opts in for you.
+Community Edition without the plugin below — is *skipped by default*: the
+reading carries an error saying so, and nothing is analysed.
+`"whenBranchesRefused"` in the block opts into one of two fallbacks; `skip`
+stays the default and nothing opts in for you.
+
+- `"main"` re-scans the branch as the project's **main** analysis and marks
+  the reading `MAIN` with a warning. Understand what that trades: the
+  project's own dashboard, and the platform's project reading with it, then
+  describe whichever branch scanned last.
+- `"project"` scans the branch as its **own scratch SonarQube project**
+  instead — `<key>:branch:<branch>-<hash>`, overwritten on each run of the
+  branch, and never touching the project's own dashboard. A fresh project has
+  no new-code period, so "new" is redefined as *on a line this branch
+  changed*; the reading is marked `PROJECT`, its gate is always `NONE`
+  (nothing to gate a scratch project on), and there is no new-code coverage.
+  This needs the scanner's token to hold **Create Projects** on the server —
+  check its default project visibility too, since *public* would publish the
+  code. cawdev never deletes these scratch projects; cleaning them up is the
+  operator's own housekeeping.
+
+The project itself can say which of these it needs: its Settings →
+SonarQube card offers *Developer Edition or above (or Community with the
+[sonarqube-community-branch-plugin](https://github.com/mc1arke/sonarqube-community-branch-plugin)
+installed)*, *Community Edition*, or *Not sure — find out on the first scan*.
+Set correctly, the daemon skips the doomed branch attempt and goes straight
+to the chosen fallback; left at "not sure", behaviour is exactly as above.
+**Restart the daemon after upgrading it to use `"project"`**: an older
+runner does not know the value and refuses to boot with it in its config.
 
 **A failed scan never fails a run.** A machine with no block scans nothing and
 says nothing. A machine with a block and a project with no key logs `not
@@ -1096,3 +1435,42 @@ the prompt.
 The prompt deliberately teaches the **method**, not the task. The task is in the
 roadmap entry, which the agent reads for itself with `task_current` — putting it
 in the prompt too would be a second copy that can disagree with the entry.
+
+### Codex CLI
+
+`codex` in `agentCommands` (`cawdev config agent enable codex`) lets a run name
+`codex` as its agent. It is spawned by `spawnCodex`, one `codex exec --json`
+per turn like Antigravity, and every flag it is given is in
+`../lib/codex.mjs` with what was checked against the real CLI (0.155). Sign in
+once with `codex login`; the run uses that sign-in and **not** your
+`~/.codex/config.toml` (`--ignore-user-config`, this CLI's `--setting-sources
+''`), so a model or MCP server you configured for yourself does not reach it.
+
+Codex has a sandbox the operating system enforces, and that decides what it
+may do:
+
+- **A run that must change nothing** — ASK, AUDIT, SCOPE, REVIEW, PLAN, and the
+  PLAN, VERIFY and MEMORY stages of any run — gets `--sandbox read-only`. Its
+  shell reads and cannot write, and it needs nothing from the machine. Only
+  cawdev's server is attached, narrowed with `enabled_tools` to the list Claude
+  Code would be handed, and no stage ever holds `report`.
+- **A run that writes** — CODE, INTERVIEW, MERGE, RELEASE and their IMPLEMENT
+  and TEST — must commit and push, which the sandbox refuses, and Codex has no
+  allow-list for its shell. So it runs with
+  `--dangerously-bypass-approvals-and-sandbox`, and **only on a machine that
+  allows everything** (R126); anywhere else the run fails before anything is
+  spawned, saying so.
+
+Every MCP server is marked `default_tools_approval_mode = "approve"` — in `exec`
+the approval policy is *never*, and without it every call to cawdev is refused.
+The run's token reaches cawdev's server through `env_vars`, never the command
+line, and is blanked for the model's own commands
+(`shell_environment_policy.set`).
+
+Not reached on Codex: experts (the session is told it cannot delegate), a
+project's tool rules and R51's permission prompt (both are Claude Code's
+`--allowedTools` grammar and its `approve` handler), the command half of R110's
+shield (the transcript half — secrets taken out of a result — runs in the daemon
+and applies), and live prompting (the process ends with its turn; a follow-up is
+`codex exec resume`). Skills are inlined whole, as for Antigravity. No usage
+windows are read: Codex has no `-p /usage`.