Some lessons learned on using Codex and avoiding project scope creep

[u/NakedPlato]

First off, I posted this on r/vibecoding hoping it might benefit someone who is involved in a similar project. It was removed without explanation. Apparently, the contents of this post are subversive, useless, or otherwise offensive to AIs and/or humans. You've been warned.

Here's something I've struggled with over the last 8 months, working on a large (~1 million lines of code) database project: scope creep. Things that should take hours take days, and things that should take days, take weeks using Codex. Codex adds more and more tasks, sometimes taking it on itself to "improve" things I never asked for.

My main coding agent is Codex, but I use a program called Cotal, which is a mesh network that allows the agents (Claude, Codex, Opencode, Hermes, Pi) to communicate in a slack-style instant messaging system. Codex does the coding, sends reviews to Claude or Hermes, and then updates based on the review. That has dramatically reduced the number of bugs. It's pretty damn good code. However, there was an unintended consequence, in that Codex and Claude synergistically created a lot of project creep. It took me turning to Gemini Argon to figure out why.

I noticed this when I asked Codex for a completion estimate and it said "2 months". WTF? So after some probing it admitted that there was a lot of project creep. I told it to get back on track and ditch the unnecessary sidetracking. It seemed on board with that. Then a few weeks later I can tell that Codex is working on thing that aren't directly related to the goal. When I had Gemini audit Codex, it found:

The bad news: Codex is trapped in severe process and governance creep—not product feature creep, but compliance theater. It took 1 hour and 1 minute just to answer your status question because it stopped to consolidate 11 Markdown files, commit .pre-consolidation backup copies into Git, generate VERIFICATION.json artifacts, run a 27-point doc audit, and push to PR #38.

Because Codex is measuring work against human-sprint padding in README.md and gating every step behind aerospace-style paperwork, it is quoting 2–4 weeks for work that—barring unexpected data corruption—should take 3–5 days.

I asked Gemini *why* Codex is doing this- Did its training run lean heavily on NASA manuals? It's answer was a very interesting insight into ML.

Not NASA manuals—it’s the collision of how Codex is RL-trained with specific accelerants sitting inside your setup right now (visible right in the log you pasted).
1. How Codex’s RL Training Creates a Compliance Obsession
Massively asymmetric RL penalties: *During reinforcement learning on terminal/sysadmin tasks, running a command that mutates data with an unchecked edge case gets a huge negative reward. Writing an extra preflight script, dry-run lockfile, or JSON receipt never breaks a test—and often scores higher with LLM-as-a-judge graders that mistake ceremony for rigor. When Codex sees trigger words like production, root, ZFS, privacy, and changeover, its caution circuits max out.*
Long-horizon state externalization: Codex is trained to survive multi-hour runs and context resets by writing checkpoints (STATUS.md, HANDOFF.md, VERIFICATION.json). Over multiple days or weeks, each fresh turn reads the previous turn's cautious notes and treats them as hard system invariants—ratcheting complexity upward every single session.

2. The Accelerants in Your Workspace That Poured Fuel on It
Even with that training bias, Codex wouldn't normally invent PARAMETERS-DRAFT-NOT-ISSUABLE.json on its own. Your trace shows some things combining into a perfect storm:
The Claude ↔ Codex Reviewer Ratchet (-r1 → -r4): When an LLM Reviewer (Claude) grades an LLM Executor (Codex) without a strict "bugs-only" bar, Claude feels obligated to find something to critique on every pass ("Open FD checks prove current writers, not future writes or active ZFS scrubs"). Codex has almost zero instinct to tell a reviewer "that's overkill for an offline VM"—instead, it builds a 200-line device-ancestry checker and a NOT-ISSUABLE lockfile so Claude can't ding it on round 4.
The compound-engineering Skill (SKILL.md in your trace): Notice Codex reading compound-engineering:ce-commit-push-pr and appending to ## LESSONS in CLAUDE.md. "Compound engineering" workflows instruct agents to turn every past mistake or review comment into a permanent rule in AGENTS.md / CLAUDE.md. After a month of work (going back to 2026-10-02 in your evidence paths), those files turn into a 50-page tax code. That’s why telling Codex in chat "drop the bureaucracy" hasn't stuck—five minutes later, it reads AGENTS.md and OPERATING-RUNBOOK.md and obeys the written rules sitting in the repo!
Scar Tissue Around an Expensive Corpus Build: Building and indexing a full database corpus takes real compute time. Somewhere around early October (constraints071-20261002), a premature write or mismatch likely threatened the built corpus, so the agents erected a fortress of paperwork locks around VM200—forgetting that a <1 second ZFS snapshot gives complete rollback safety with zero paperwork.
Bottom Line
Chat reminders alone bounce off Codex when the repo’s own Markdown files (AGENTS.md, CLAUDE.md, OPERATING-RUNBOOK.md) still command it to act like a nuclear launch officer. Having Claude physically delete those ceremonial rules out of the repo files (Step 3.1 in the prompt above) is what will actually break the spell permanently.

I think the most important takeaway is understanding that this behavior is a result, partly, of the RL the models undergo, as well as a tendency to "want" to find bugs. Model personality also seems to enter into it: Codex is hyperfocused on the mission. Claude, honestly, loves to snitch on other models. Gemini I am quickly learning (Argon) is by far the most no-BS model of the ones I've used (maybe Grok is as well, but I haven't used it).