Codex can work for long stretches, especially when a /goal gives it a persistent objective. The harder part is staying oriented while it works for hours or days, uncovers new implementation details, and moves through several kinds of verification.
Early assumptions often change once implementation begins. The collaboration model needs to preserve the objective while giving both you and Codex room to revise the plan as new evidence appears.
Over the last few weeks, I have been using five practices:
- Let Codex plan the work and maintain the roadmap.
- Keep the main thread focused on coordination.
- Audit the roadmap and review the code after each milestone.
- Use local threads for Computer Use testing.
- Report progress through concise updates and dashboards.
Generated with GPT Image 2 in Codex
1. Let Codex plan the work and maintain the roadmap
I usually begin with a conversation rather than /plan mode. I describe what I am trying to build, dictate rough thoughts, share constraints, and let Codex ask questions until it has enough context to propose an initial plan.
This keeps the early discussion flexible. I do not need to turn half-formed ideas into a formal specification before Codex can start helping. It can interview me, reflect back what it understood, identify gaps, and gradually turn the conversation into a workable plan.
As the project takes shape, I ask Codex to set the current Goal. Goal mode gives Codex a persistent objective, allowing it to keep working toward the same outcome across multiple turns until the goal is complete, blocked, or replaced.
I can set the goal myself with /goal, but I usually ask Codex to do it. Goal mode is exposed through the harness, so Codex can synthesize our conversation, the project context, and everything it has learned so far into a clear objective. It can also define the evidence required before considering that objective complete.
For larger projects, I ask Codex to write the broader roadmap into GOALS.md. This is a project convention rather than a built-in Codex feature, and the file can be named whatever you prefer.
I usually organize GOALS.md around milestones instead of a flat task list. Each milestone records:
- the intended outcome
- the work currently in scope
- important decisions
- known blockers
- the evidence required before moving on
Codex maintains the file as the project develops. New findings may change the scope of a milestone, introduce another one, or change the evidence required for completion.
Only one Goal-mode objective is active at a time. As milestones are completed, Codex updates GOALS.md, activates the next objective, and continues working toward it.
2. Keep the main thread focused on coordination
Once the roadmap exists, I keep the main thread focused on the objective, constraints, decisions, and current project state.
It decides what should happen next, delegates bounded tasks, and evaluates the results. It does not need to carry every implementation detail.
A worker may spend an hour reading unfamiliar code, trying several approaches, or tracing a failing test. The coordinator only needs the information that affects the wider project:
- what the worker learned
- what changed
- the supporting evidence
- what should happen next
Codex can delegate this work to a subagent or create a separate thread. Functionally, they can perform the same task. I use a separate thread when I expect to revisit the work later, since it remains visible in the Codex app and keeps its own history.
This becomes especially useful once several pieces of work are running in parallel. The main thread can continue coordinating the project while each investigation, implementation, or review remains easy to inspect.
3. Audit the roadmap and review the code after each milestone
GOALS.md reflects what was known when Codex last updated it. By the end of a milestone, the project has usually uncovered something new.
Before moving on, I ask another thread to compare the roadmap with the current state:
- Is the milestone actually complete?
- Is the next goal still the right one?
- Are any milestones missing?
- Has new evidence changed the order of work?
- Does the definition of done still hold?
I run this audit at the end of each milestone, as well as whenever new evidence materially changes the direction of the project.
I also run /review on the implementation.
Suppose the implementation and remote tests for a sign-in flow are complete. The roadmap audit may notice that no one has tested the flow in a real signed-in browser. At the same time, /review may find that the new path stores a token incorrectly even though the remote tests pass.
The coordinator updates GOALS.md, delegates the token fix, adds the missing browser verification, and only then activates the next milestone.
I usually keep audits and reviews in separate threads. A subagent could perform the same work, but a separate thread leaves a visible record that I can return to later.
4. Use local threads for Computer Use testing
Most of my Codex sessions run on a remote instance, so work can continue while my laptop is closed. Some checks still depend on my local machine:
- a signed-in browser
- local credentials
- Xcode
- macOS permissions
- the iOS Simulator
The remote coordinator can create a local thread for one of those checks. I apply the remote diff or check out the relevant branch or commit so the local thread tests the correct code.
The local thread operates the browser or application and returns screenshots, logs, and findings. When a check fails, a remote worker fixes the issue and the local thread tests again.
A typical loop looks like this:
- A remote worker implements the sign-in flow.
- Remote tests pass.
- A local thread uses the Codex Chrome extension.
- The browser test reveals a redirect bug.
- A remote worker fixes it.
- The local thread repeats the check.
The project remains remote by default. My computer joins only for the checks that require it. The remote thread can also keep checking for the local thread to become available again when I reopen my laptop.
5. Report progress through concise updates and dashboards
Worker threads usually report on one task. When I return to the project, I need a view of the overall state:
- what is complete
- what changed
- what remains
- what needs a decision
I ask Codex to report whenever the project state changes, using three short sections:
**What’s done
What’s next
Any blockers**
Which is almost like having daily standup with Codex, albeit hourly.
Codex can send the same update through Slack, either as a direct message or in a dedicated project channel.
While I am in the Codex app, I also use /side to check in without interrupting the main thread. From the side thread, I can ask for a summary of what has been completed, what remains, and whether anything needs my help—for example, a manual click, approval, or another piece of clickops.
Getting a summary from the side thread
Asking the side thread to pass along my instructions to the main thread
I can then clarify an instruction, resolve a blocker, add context, or ask the side thread to send updated guidance back to the main thread.
For projects with several milestones or parallel workstreams, I also maintain a progress-dashboard.html. This is a custom project artifact rather than built-in Codex UI. It can show:
- the active goal
- completed milestones
- evidence
- blockers
- decisions
- recent updates
When I return after several hours, I can understand the state of the project without reading every worker thread. Codex can also deploy the dashboard as a Site so that it remains accessible remotely.
Summary
I use this structure when a project is likely to uncover new information, involve several independent pieces of work, or require evidence from more than one environment.
The workflow follows a simple cycle. Codex turns the initial conversation into a roadmap, activates one milestone, delegates the work, and checks the result before moving on. Local threads handle the checks that require my machine, while updates and dashboards help me return to the project without reconstructing everything from scratch.
The important part is keeping the project state current enough that the next decision reflects what Codex has actually learned.
Try it
Paste this into a new Codex thread:
Coordinate this as a long-running project.
Begin by interviewing me about what I am trying to build. Let me describe rough ideas and constraints conversationally, then turn that discussion into an initial plan.
Create GOALS.md as the shared roadmap. Organize it around milestones, with the intended outcome, scope, decisions, blockers, and evidence required for each one.
Set and maintain one Goal-mode objective at a time. The active objective should correspond to the current milestone.
Keep this thread focused on the objective, constraints, decisions, and project state. Delegate implementation to subagents or new threads.
Require workers to return conclusions, changes, and evidence rather than full transcripts.
Use separate threads when I may want to inspect, continue, or review the work later. Use subagents for bounded work that does not need its own visible history.
After each milestone, use a separate thread to audit GOALS.md against the current state and run /review on the implementation. Update the roadmap before activating the next objective.
Use local threads for Computer Use testing that depends on my browser, desktop applications, permissions, credentials, or device state.
*When the project state changes, report only: - What’s done - What’s next - Any blockers*
Maintain progress-dashboard.html when the project spans several milestones or workers. Do not declare completion until the agreed evidence exists.
Alternatively, you can also take an Appshot of this article and ask Codex:
Create a reusable Codex skill named orchestrate-projects from this article.
Preserve these practices:
*- let Codex interview me and create the initial plans - use GOALS.md as a milestone-based roadmap - keep one Goal-mode objective active at a time - keep the main thread focused on coordination - audit the roadmap and run /review after each milestone - use separate threads for work I may want to revisit - use local threads for Computer Use testing - report progress through concise updates, Slack, and progress-dashboard.html*
