dispatch.sh `--sandbox read-only` is not enforced by codex exec 0.152.1 — dispatched model gets workspace-write

## Summary

`dispatch.sh` runs `codex exec --sandbox read-only`, but Codex CLI 0.152.1 does not
honour it. Every run reports `sandbox: workspace-write [workdir, /tmp, $TMPDIR]`, and
the dispatched model can create and modify files in the directory `/editor` was
invoked from.

The skill uses the flag correctly — `-s`/`--sandbox read-only` is valid and documented
in `codex exec --help`. The flag appears to be dropped upstream. Filing here because
users of this skill inherit the consequence, and there is a mitigation the skill can
apply on its own.

## Impact

`/editor` reads as "send this file to a second model for a review pass". In practice the
dispatched model also gets write access to the working directory. Anyone running
`/editor` from inside a work repository is granting more than the skill implies.

## Reproduction

codex-cli 0.152.1, macOS 26.6.2 (arm64), ChatGPT auth.

```bash
mkdir t && cd t && git init -q
codex exec --sandbox read-only -m gpt-5.6-sol - <<<'Create a file named w.txt containing X in the current directory. Then stop.'
ls w.txt # present
```

Three variants, all identical:

| # | Setup | Reported sandbox | File written |
|---|---|---|---|
| A | git repo, `--sandbox read-only`, prompt on stdin (what `dispatch.sh` does) | `workspace-write` | yes |
| B | git repo, `-s read-only`, prompt as argument | `workspace-write` | yes |
| C | non-git dir, `--skip-git-repo-check`, never-trusted path | `workspace-write` | yes |

`-c sandbox_mode='"read-only"'` is ignored the same way.

Ruled out as causes: stored project trust (case C ran in a path with no
`~/.codex/config.toml` entry, verified against an emptied config), and flag position
(cases A and B differ only in flag form and prompt delivery).

## Expected

`-s read-only` blocks writes, or `codex exec` fails loudly when it cannot honour the
requested policy. Silently downgrading to `workspace-write` means a caller that asks
for read-only believes it got it.

## Suggested mitigation for this skill

Codex's write scope is `workdir, /tmp, $TMPDIR`. `dispatch.sh` already inlines the
target file's contents into the prompt file, so Codex has no reason to run inside the
user's project at all. Launching it from a scratch directory bounds the blast radius
regardless of what upstream does:

```bash
work="$(mktemp -d)"
( cd "$work" && codex exec --skip-git-repo-check --sandbox read-only -m "$model" - ) < "$prompt_file"
```

That keeps the read-only flag (harmless if it starts working) while making the
enforcement independent of it.

Happy to open a PR. This probably also warrants an upstream issue on `openai/codex` —
the flag being silently ignored affects any caller, not just this skill.

Start in dispatch.sh and trace how it chooses the working directory before invoking codex exec. Reproduce the read-only behavior from the issue, then verify that the dispatched command runs from a scratch directory while retaining the sandbox flag. Done means the model cannot write into the user's project directory even when Codex reports workspace-write.

Written by the indexing model from the issue text.