Codex is very good at focused execution.
But once a task gets a little bigger, a familiar problem shows up: the work starts living in chat memory.
You clarify the task in one turn, research a few gaps in the next, begin implementation, then come back later and wonder:
- What exactly was the agreed scope?
- Which part is done?
- What is the next safe step?
- Can I trust the current state, or am I already drifting?
That pain point is why I built Quick Codex.
It is an open-source, lightweight workflow layer for Codex CLI. The goal is simple: make medium-sized work more resumable, auditable, and harder to derail.
Not bigger. Not more complex. Just more durable.
The problem is not coding, it is continuity
In my experience, raw Codex is strongest when the task is already clear and the execution window is short.
The trouble starts when a task spans multiple turns and the workflow stays implicit.
Something like this happens:
- You explain the problem
- Codex explores a few files
- A plan starts to form
- Implementation begins
- Context gets fuzzy
- The next step is no longer obvious
- Drift starts
At that point, you are not fighting code generation anymore. You are fighting state loss.
That is the gap Quick Codex is trying to close.
What Quick Codex actually does
Quick Codex adds a small local workflow surface around Codex CLI.
Core capabilities
-
qc-flow→ front-half work -
qc-lock→ strict execution
CLI utilities
- status
- resume
- doctor-run
- repair-run
- lock-check
- verify-wave
- close-wave
Key idea: workflow state should live in files, not only in chat memory.
Two modes, two different jobs
qc-flow
Use when the task is still unclear.
qc-lock
Use when the scope is already defined and needs strict control.
Example commands
npx quick-codex install
node bin/quick-codex.js status --dir /path/to/project
node bin/quick-codex.js resume --dir /path/to/project
node bin/quick-codex.js doctor-run --dir /path/to/project
Top comments (0)