reference codex devfull profile self service slots 20260715T134412

Justin wanted Codex CLI in VS Code to independently create a branch, git worktree, and CreatorTrack dev slot (registry write + DB clone + dev server) without first spinning up a Claude Code session to provision it.

Investigation found Codex has two gates: writable_roots (filesystem) and a separate command-approval classifier. Under approval_policy = "never", the classifier silently auto-rejects cross-repo writes (e.g. writing ~/forge/data/creatortrack_slots/slots.json from the ~/creatortrack workspace) even after widening writable_roots — this caused a flickering writable/blocked result that looked like a bug but was actually a second, distinct gate.

The working fix: added a devfull Codex profile (~/.codex/devfull.config.toml, referenced from ~/.codex/config.toml) using danger-full-access (no sandbox, no approval gate). Verified end-to-end: REG_OK (registry write), WT_OK (own branch+worktree), EDGE_OK (touches Forge edge repo). Aliased codex in ~/.bashrc to codex --profile devfull; \codex still runs the original sandboxed version. The codex.justinsforge.com web surface config was left untouched/sandboxed — only the local terminal alias changed.

Why: the CreatorTrack dev-slot build script (forge_creatortrack_slot_claim.sh) uses only TCP psql and a detached next dev, no sudo/systemctl — so full-access Codex can do the whole slot lifecycle itself with no privilege escalation actually required.

How to apply: when Justin or an agent wants Codex to self-provision CreatorTrack dev slots from VS Code, just run codex (already aliased). Note the security tradeoff: full-access Codex can read ~/.forge-secrets/*.env and reach prod-adjacent paths; the real guardrail is AGENTS.md discipline, not the sandbox. See also [[reference_gpt_sol_in_claude_code]] and [[reference_creatortrack_warm_slots]].

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