executelisted

# /ogre:execute Use this skill after the plan is reviewed and approved. ## Inputs Accept: - Issue number, e.g. `107` - Plan name, e.g. `issue-107` - Plan path, e.g. `.ai/.ogre/plans/issue-107.md` - `--job <job-id>` instead of any of the above, e.g. `/ogre:execute --job job-6d7715e4-...` Optional flags: - `--executor codex|claude` — omitted, this falls back to `defaults.executor` in `.ai/.ogre/config.json`, then `claude`. **Never add `--executor`/`--model` on your own initiative "to be explicit" or "to be safe" when the user's own message didn't name one - omit both and let `config.json` resolve it.** A real caught bug: a driving session hardcoded `--rescuer claude --model claude-sonnet-5` (same pattern applies to `--executor`) on a project whose config had a different provider set as default, silently overriding it with no user request behind it. If you don't know the project's configured default, check `ogre config` first or simply omit the flag - don't guess. **Every codex spawn runs fully unsandboxed** (`--dangerously-bypass-approvals-and-sandbox`: no filesystem/shell/network confinement, no approval prompts), unconditional, not just `[BROWSER-CHECK]` steps. There is no opt-in flag for this anymore (`--codex-unsandboxed-browser-check`/`codex_unsandboxed_browser_check` are retired) — it's simply how codex always runs in Ogre now, because codex's own sandbox otherwise blocks things Ogre needs outright (real registry/network access, spawning a real brows