Has anyone automated a ChatGPT <> Codex orchestration loop?

[Ja_cob]

I’m trying to work out whether anyone has already solved a workflow problem that I suspect is better described as agent orchestration rather than simply automation.

At this point in the development workflow I already have the architecture, development strategy, roadmap, experiment methodology, decision boundaries, and human-approval points reasonably well defined.

The remaining bottleneck is mostly execution/transport.

The rough model is:

ChatGPT / reasoning layer
→ determines the next governed task or experiment
→ Codex executes it against the repository
→ files/state are modified and experiments/tests are run
→ results/artifacts come back to the reasoning layer
→ the reasoning layer reviews the evidence and decides the next step
→ repeat, or escalate to the human when an actual judgement call is required.

Right now the manual part remains unnecessarily involved in parts of that loop: transferring instructions, making sure the right files are available, starting execution, bringing experimental results/state back, etc.

I have explicitly governed state, explicit decision points, experiment records, and places where the system must stop for human judgement, and I’m trying to automate the mechanical layer around that process.

Something roughly like:

planner/reviewer → Codex → repo/files → experiment → results → planner/reviewer → next task

Ideally with:

• the repository/files acting as durable state rather than relying on chat memory;

• automatic artifact/result handoff;

• traceability of what happened;

• retries/failure handling;

• explicit human approval gates where required;

• the ability for the planner to generate the next task based on the resulting state.

Has anyone built something like this successfully?

In particular, I’m curious whether the best current approach is:

• OpenAI Agents API;

• Codex App Server;

• Codex SDK / Codex exec;

• MCP;

• GitHub Actions or another external orchestrator;

• ChatGPT Work;

• some combination of the above;

• or something I’m completely overlooking.

The part I’m especially unsure about is the ChatGPT side. Can the existing ChatGPT experience realistically remain the reasoning/orchestration layer, or does a reliable implementation effectively require recreating that layer programmatically using an API agent?

I’d be particularly interested in hearing from anyone who has actually implemented a loop like this, including what broke once you tried to make it unattended.

[Slavax]

OA would prefer if you would use metered Codex/Work exclusively without unmetered Chat

You can still use Chat for like research/general understanding/maybe snippets of code

The limits are very generous already

But I wouldn’t expect some automatic workaround which makes little financial sense for OA

If anything they were cracking down on this including something api 2 sub not sure how it works but yeah perhaps also not the best place to ask

[aaronsamuel]

tbh kind of i see it the same as u do which i then tried to implement but not ready to share yet, id come back if it reliably works tho

[EricGT]

@Ja_cob

• something I’m completely overlooking

/goal ???

@Ja_cob

I’d be particularly interested in hearing from anyone who has actually implemented a loop like this

An instance of me using /goal is noted in this topic.

[merefield]

This is why I do most of my product development conversations directly in Codex CLI.

You can ask codex to save conclusions as architecture and roadmap documents (and anything else you want)

When you are ready you can move directly into coding without any manual cut and paste.

[T.Maillet]

I think you’re missing the point of chatGPT beeing somehow free for the reasoning and keeping codex for the actual coding allow you to save a lot of tokens.

[merefield]

Fair point, but I think it comes down to efficiency too. As a freelancer my time is valuable, and so is yours.

Cutting and pasting is laborious and inefficient.

There are other advantages to my approach:

1. Planning can take account of the actual codebase and its constraints.
2. Decisions become architecture and roadmap files alongside the code.
3. Implementation can follow directly, reducing the need to explain decisions again.

And a point often missed is that you should be aiming to monetize your time and your output so that ultimately they are paid for by the revenue you get back.

I appreciate this is a Topic about automating this.

But if this was ever automated, then OpenAI would have to start considering using the very same quotas because obviously people would place more burden on ChatGPT - which is utilising the very same limited compute.

[T.Maillet]

Those are also extemely fair point

On my end I’m a plus user. And to use the most of codex quota for as long as it remains affordable I have to keep the reasoning in ChatGPT.

I totaly agree, if they automate it they will make it so it uses the quota for sure.

I think they are 100% aware of the fact that many people do use ChatGPT for the reasoning but why would they automate something that would make them lose money.

Factually speaking it is already “automated”. Codex uses the same (sometime even more advance model) than ChatGPT. So if you had infinite quota you could do as you Merefield do and keep it all in codex. That sounds like the obvious answer. On that I can’t argue.

[merefield]

Yeah, for the time being I think working within the limits you have with any workaround that is within Terms of Use is completely reasonable.

I appreciate that on Plus, quotas are particularly tight and you have to squeeze out every quota efficiency you can

[floam]

ChatGPT plugin from OpenAI can connect to remote environments from Chat. Showed up as an installable plugin earlier. Cloud Agent feature

[Pimpcat]

Yes. I have been running this pattern for the last few days. The key insight is that it works better as a durable supervisor with ephemeral workers than as one
autonomous agent that stays alive indefinitely.

The loop looks like this:

durable state → supervisor → fresh worker → diff, tests, and artifacts → independent verifier → next gate, retry, or human hold

The supervisor does seven things:

1. Reads the repository and current run state.
2. Selects the next bounded gate.
3. Creates a work order with scope, constraints, budget, and acceptance criteria.
4. Launches a fresh worker in an isolated worktree or scratch directory.
5. Collects the worker diff, logs, test results, and structured receipt.
6. Independently verifies the result.
7. Advances, retries with a new worker, stops when progress is absent, or requests human approval.

The workers are intentionally disposable. Each exists for one bounded attempt and then disappears. The supervisor retains the durable state, work orders,
artifacts, and gate results, rather than the worker conversation. This avoids stale assumptions, context pollution, accidental scope expansion, and workers
defending an earlier failed approach.

A worker receipt might contain:

run_id
gate
attempt
changed_files
commands_run
test_results
artifacts
blockers
suggested_next_state

The supervisor never treats “the agent says it succeeded” as evidence. It reopens the diff and runs the acceptance gates itself. Repeated identical failures
produce a hold instead of infinite retries.

ChatGPT can remain the human facing reasoning and planning layer, but it should not be the unattended scheduler or source of truth. Unattended execution
requires an external runner with repository access, process control, persistent state, budgets, and explicit promotion gates.

The transport is less important than the separation of responsibilities. Codex CLI, Codex App Server, an API worker, or the Agents SDK can provide the worker
and tool layer. MCP can provide tools. The supervisor should still own durable state, retries, verification, and promotion. OpenAI’s current guidance points to
the Responses API for reasoning and tool calling workflows, and the Agents SDK for orchestration, tracing, handoffs, and state management. Responses guidance

The main lesson is simple: do not ask the model to supervise itself. Use models as bounded, disposable workers and put the control loop in deterministic
software. Start with one repository, one gate, one worker, one receipt, and one verifier. Add concurrency only after that loop is reliable.

[Ja_cob]

This looks extremely close to the missing piece I was trying to describe. Is Codex Tasks (Internal/CCA) available in ordinary Chat, or was this part of a limited/internal rollout? because I can’t find it : (

Also, when a remote task completes, can that completion trigger or resume the same ChatGPT conversation automatically, or does the user still need to prompt ChatGPT to read the result?

What interests me most is whether a loop like ChatGPT → create Codex task → task completes → ChatGPT reviews result → creates next task can run until an explicit human decision gate is reached.

[Ja_cob]

Your architecture sounds very close to what I’m trying to achieve. ChatGPT as the architecture/review layer, durable project state outside model context, and disposable Codex workers executing bounded packets.

Could you kindly elaborate: in your automated loop, what actually takes the bounded packet from ChatGPT Web and invokes codex exec --ephemeral, and how does the resulting terminal evidence get returned to the ChatGPT review session?

Does ChatGPT then resume automatically, or is there still a human prompt required at that boundary?

I’m deliberately trying to keep the Codex worker from deciding its own next task; the controller/reviewer should make that decision.

[Pimpcat]

I use ChatGPT to develop the plan, then hand it to my own runner using Codex via the API. From there, a supervisor manages disposable workers against bounded tasks and checks the returned evidence before deciding what happens next. The workers don’t choose their own next task.

The ongoing execution loop runs outside ChatGPT Web, so it doesn’t depend on automatically resuming the conversation after each task. I’m keeping the implementation details private for now, but that’s the broad separation of responsibilities.

5.6 SOL Max for architectural planning webchat. 5.6 Luna xhigh supervisor that runs 5.6 Luna high disposable workers. It can run 1 to 10 workers at a time too no problem at all. It’s also the cheapest way to code and the easiest way to manage context.

[mblofeld]

I’ve actually been experimenting with a somewhat different version of this.

Rather than using Codex/API workers for the normal loop, I’m using an ordinary ChatGPT conversation as a project supervisor, with separate ordinary ChatGPT chats as replaceable application workers. A local Windows tool I’m building handles the deterministic side: Git/task branches, tests, checkpoints, provenance, diagnostics, packaging/deployment, etc., with GitHub as the durable source of truth.

The important part is that the chats aren’t authoritative state. A worker can disappear or be replaced and the next worker recovers from the durable assignment, current source and checkpoints rather than needing the previous chat history.

The motivation was partly cost. I found Codex very effective, but a lot of its usage was being spent around deterministic operations that don’t really require another model turn. Moving those into the local harness lets me use the normal ChatGPT Plus conversations for the reasoning and reserve Codex, if needed at all, for problems where its autonomous edit/test loop is genuinely valuable.

It isn’t fully unattended at the ChatGPT boundary yet — I still initiate the worker interaction — but the development task itself is durable and recoverable outside the chats.

It sounds quite close to what you’re describing, except I’m deliberately seeing how far the architecture can go without requiring Codex/API usage for the normal development cycle.

[TheLagBorn]

Check this out, I’ll be uploading the update of Not-Code soon, I think this is what you want to achieve, but I’m dealing right now with agent collision, improving the FIFO system and dealing with ngrok free tunnel limits in addition to the OA silent nerf of 25-26 minutes limit for tooling session that added august 20, follow me on X to know exactly when I ship the update to Microsoft Store. Luis Camilo Salgado Reyes on X: "Not-Code is naturally evolving into an autonomous AI Agent Bot. That evolution came from a real engineering constraint: around August 20, we began consistently hitting a ~25–26 minute MCP tooling/session limit when running long-lived agents through ChatGPT. Instea… / X

[anfedoro]

I may offer the way I use.. look here - A practical setup for using ChatGPT as a supervisor around Codex and Work.

[RagnarOath-Taker]

The durable-supervisor / disposable-worker pattern described here is very close to where I’ve converged too.

One boundary I think deserves to be first-class is the step between “the next piece of work exists” and “launch an agent to do it.”

I don’t think planned work should automatically become agent work.

Before execution, I think the control layer needs to derive at least:

• the canonical work identity;
• who or what is responsible for it;
• what information is actually required;
• the minimum authority/effect ceiling;
• whether the execution modality should be deterministic software, a human, a bounded agent, or a composition;
• whether the proposed worker is qualified for that work;
• and what independent evidence will count as completion.

That changes the loop from roughly:

planner → agent → reviewer

to:

govern work → allocate → authorize → execute → independently verify → reconcile state.

I’d be interested in whether anyone here has implemented that allocation/authority boundary independently of the model/provider, especially when workers can be substituted between attempts.

Drafted with AI assistance and reviewed by me.

[rafa3]

Not fully… A lot of things I still doing manually, but just because I can use GPT Sol in ChatGPT without consuming my Codex limits. But it’s being a good experience until now.