Codex CLI project management

Codex CLI project management is the practice of putting a plan and a review step around a terminal coding agent. Codex CLI runs in your terminal, takes a prompt, reads and edits files in a working directory and runs commands under a sandbox and approval policy you choose. Like any such tool it is stateless about your project as a whole. It does not know that card ENG-7 depends on ENG-3, that ENG-9 is on hold, or that the last attempt at this change was rejected for touching the wrong module. If you run several tasks a week, the plan ends up in a text file and the verdict ends up in your head. The aim of a workflow here is modest: make the task explicit before the run, keep the boundaries declared during it, and keep the outcome recorded after it, so that accepting work is a decision you make on evidence.

How Codex CLI behaves on its own

Codex CLI works against a directory you point it at. It offers sandbox modes that range from read only to writing within the workspace, and approval settings that decide when it must ask before running a command. A read only sandbox is a sensible first pass for a task you have not scoped well: the agent can inspect the code and describe a plan without being able to change anything. Non interactive invocation lets it run from scripts, which is what makes scheduled use possible. Two things are worth knowing. The sandbox and approval choices are yours to make on every run, so they are only as consistent as your habits. And the tool has no concept of a backlog. It will attempt whatever you hand it, including a task that was blocked or already finished, because nothing in the session tells it otherwise.

A review-first loop for Codex work

A practical loop for Codex has the same shape as for any agent but leans on its sandbox modes. Begin with a read only assessment: ask for the relevant files, the proposed change and the risks. Compare that with the task's scope. If it matches, start a write capable session with a narrow scope and a defined completion check. Afterwards, read the result as a reviewer would: which files changed, whether they were inside the declared scope, whether the check ran, and what the agent claims versus what the evidence shows. Record the outcome somewhere a later reader will find it. Resist the shortcut of treating a session that ended cleanly as a task that finished well. Process exit and correctness are different facts, and a review step exists precisely because the agent's own report of success is the least independent evidence available.

Running Codex from a Liquid Brain card

Liquid Brain lets you open Codex from a card, with its working context close at hand [C1b]. The Desk also supports explicit scheduled review or work tasks, with readiness and authority checks before execution [C1c]. Because proposed scope and approved execution authority are kept separate, writing a scope on a card does not by itself authorize a run [N09]. Command guards and scope controls can be configured to check work against declared boundaries [C5]. Gates can run before work is accepted, and attempts, outcomes and reported usage are recorded with the card [C4]. Missing usage is shown as unknown, not zero [N06]. This requires a configured, compatible Codex CLI installed on your computer. Liquid Brain does not bundle or replace it, and compatibility with every CLI version is not promised [C10].

QUESTIONS

Do I need Codex CLI installed to use Liquid Brain with it?

Yes. Opening Codex from a card needs a configured, compatible CLI on your computer [C1b]. Liquid Brain does not include or substitute for it, and it does not promise compatibility with arbitrary CLI versions or setups. Install and test Codex CLI by itself first, then use the card to launch and organize the work around it.

Does a card's scope let Codex edit those files automatically?

No. Proposed card scope is kept separate from approved execution authority, and a card edit does not automatically grant permission to run [N09]. Scheduled tasks also pass readiness and authority checks before they execute [C1c]. Writing a scope on a card is a statement of intent, and approval remains a distinct decision you make.

How is Codex CLI project management different from just running codex in a terminal?

The difference is the record around the run. A card states the scope and completion criteria, bounded context can be assembled for the task [N11], and attempts and outcomes are recorded so you can review them afterward [C4]. The agent's own behavior inside the session is unchanged, and you still make the acceptance decision.

RELATED GUIDES

• Cards vs scheduled tasks: what starts an agent?
• How to preview work with the Liquid Brain harness CLI
• How to read Liquid Brain reports and provenance

RELATED HARNESS PAGES

• Claude Code project management Claude Code project management as a workflow: run Claude from project cards, schedule tasks and review results before you accept them.
• scheduled agent tasks Scheduled agent tasks done carefully: explicit prompts, readiness and authority checks, and why a started run is not a finished one.
• multi-agent project coordination Multi-agent project coordination: keep Claude and Codex work on one project organized with shared cards, scope, authority and review.