I’ve been experimenting with giving Codex a rough goal instead of very specific instructions, then letting it decide what to do next across multiple loops.
I made a small local tool for this: it keeps a checklist, reviews the last result, and chooses the next action.
Still very early. Curious if anyone else is trying similar workflows, or has suggestions.
The repo is here if anyone wants to take a look: GitHub - kunkunzhishan/codexloop: A local Codex CLI loop for longer tasks with planning, review, checklist state, and audit logs. · GitHub
Great stuff!
Are you aware of the /goal slash command?
This allows you to set a longer term goal for Codex CLI out of the box. It’s currently in experimental settings.
Also have you considered a more friendly username given your link is a little more transparent about who you are? 
(Update I see you have done this, nice)
Hi and welcome to the community!
Very interesting!
What is your experience with models choosing shortcuts to reach the goal instead of actually doing the work?
I ran into this a few times recently. I was too optimistic and expected the model to follow through, but instead it found the shortest path to satisfy poorly defined goal criteria.
Needless to say, I had to go back to the basics and implement a proper sequence of gates before continuing with this approach.
Thanks! I’ve also been looking into /goal and related long-running objective workflows. There is definitely some overlap.
The angle I’m exploring with CodexLoop is automatic expansion + usability for longer runs. When Codex works on a broad goal, it often discovers follow-up work: bugs, missing tests, docs gaps, polish, product ideas, etc. I want the loop to capture those discoveries, organize what is active vs deferred, and still know when to converge.
So CodexLoop keeps external state like checklist, deferred ideas, review history, audit logs, and restart/continue behavior. The goal is to make longer Codex runs easier to inspect, resume, and control.
Yes, definitely. I run into this quite often.
In many cases, the model gives me a degraded version of the deliverable: something that technically satisfies part of the goal, but is not really what I wanted. This has been one of the most frustrating parts for me.
I also ran into this while building this small plugin. When the task is too large or too loosely defined, the model tends to downgrade the work and produce something that is hard to actually ship.
CodexLoop is partly an attempt to avoid this problem.