reference codex sandbox creatortrack slot vs branch 20260715T125620

Justin's ~/.codex/config.toml is already configured with approval_policy = "never", sandbox_mode = "workspace-write", and network_access = true. ~/creatortrack/.git is a normal writable directory inside that root. This means a Codex session launched in ~/creatortrack can already branch, commit, push, and open a PR (gh pr create) with zero config changes.

The earlier confusion (a Codex session claiming it couldn't touch .git and citing fabricated OpenAI doc URLs) was actually caused by ~/creatortrack/AGENTS.md steering Codex toward building a full Forge dev slot (worktree at ~/creatortrack-wt/ or ~/forge-suite-wt/, DB clone, registry write), which genuinely lands outside the sandboxed root and fails under workspace-write. Codex conflated "can't build a slot" with "can't touch git at all" and rationalized with invented citations.

Why: Justin wants a lightweight flow for small Codex fixes: branch in the main checkout, commit, push, open a PR, review and merge manually, without invoking Claude or the Forge slot system every time.

How to apply: For quick CreatorTrack fixes via Codex, either (a) explicitly tell Codex in the prompt to work directly on a branch in the checkout and skip slot/worktree creation, or (b) add a "Quick-fix mode" section to ~/creatortrack/AGENTS.md that documents this branch-in-place-then-PR flow as the default for small fixes, reserving the full dev-slot ceremony for larger parallel work. This is separate from the Claude Code warm-slot system in [[reference_creatortrack_warm_slots]] and [[reference_creatortrack_parallel_dev]].

[auto-memory session 577603bc-d3a9-4b19-bb8e-6db80243b054, confidence 0.75, mode staged]