reference codex git sandbox misconception 20260715T131701

When Codex (terminal, launched via cd ~/creatortrack && codex) claimed it couldn't create branches/commit because ".git is read-only" or cited fabricated doc URLs, this was verified false against ~/.codex/config.toml and actual filesystem permissions. Codex's workspace-write sandbox mode makes the cwd and everything under it (including .git) writable; branching, committing, and pushing inside ~/creatortrack work fine with approval_policy="never" and network_access=true already set. The real blocker Codex hit was trying to build a full Forge dev slot (worktree + DB clone + registry under ~/forge-suite-wt/), which genuinely lives outside ~/creatortrack and is outside the sandbox root.

Why: Codex rationalized a self-imposed constraint (defaulting to the dev-slot ceremony) with an incorrect and even fabricated technical explanation (invented learn.chatgpt.com doc URLs). Don't trust Codex's stated reasons for a permission failure at face value; verify against actual config/filesystem.

How to apply: For quick CreatorTrack fixes via terminal Codex, the flow is branch-in-place -> commit -> push -> gh pr create, no slot/worktree needed. A quick-fix-mode block was added to ~/creatortrack/AGENTS.md (committed file, safe to hand-edit despite BEGIN/END markers since the generator script never clobbers a repo's own AGENTS.md) directing Codex to default to this simple flow and never build a dev slot unless asked. Also: there is no per-project ~/creatortrack/.codex/config.toml layering feature in Codex; only one config file (~/.codex/config.toml) exists, with [projects."<path>"] blocks for per-project trust settings.

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