I have been testing a workflow in which a local Codex/Work run uses ChatGPT Web as an external reasoning and orchestration layer.
The original need is practical: long-running local tasks often require intermediate analysis and redirection. Today, the user normally has to inspect the result, decide what should happen next, and manually restart or redirect the agent.
I wanted to test whether ChatGPT itself could perform that orchestration while Codex remained the local executor.
The resulting loop is:
Local Codex/Work → ChatGPT Web → next instruction → local execution → result back to ChatGPT → next instruction
### What I tested
I progressively validated:
1. **Wake-up**
- A local Codex run opens ChatGPT Web in an authenticated Chrome session.
- It sends a message.
- ChatGPT responds normally.
2. **Two-way loop**
- ChatGPT returns a deterministic next instruction.
- Codex reads that instruction.
- Codex performs the local action.
- Codex returns the result to the same ChatGPT conversation.
3. **Multi-turn loop**
- A → B → C → D → FIN
- Same local Codex run.
- Same Chrome session.
- Same ChatGPT conversation.
- No new Codex/Work launch between steps.
- No additional approval dialog observed.
- All expected local outputs were verified.
4. **Text bridge**
- Codex reads locally produced content.
- It pastes the result into ChatGPT.
- ChatGPT analyses it and returns the next structured action.
- Codex executes it locally and reports the status back.
This worked successfully end-to-end.
### Simplified architecture
ChatGPT Web = reasoning / orchestration layer
Local Codex/Work = execution layer
### Why this is useful
This enables a practical asynchronous workflow for long-running tasks:
- local execution,
- result reporting,
- reasoning / validation by ChatGPT,
- dynamic redirection,
- continuation of the same local run.
The user does not need to manually re-orchestrate every intermediate step.
### Current observations / limitations
- Text-based result transfer works reliably.
- Direct attachment of locally generated files into ChatGPT Web was not reliable in my tests.
- The native ChatGPT Windows app could not be controlled through computer-use in the same way, while ChatGPT Web could.
- I reproduced the multi-turn behavior across successive Windows builds, including 26.930.21537 and 26.930.31730.
- I did not observe a new approval dialog between intermediate steps inside the already-running local Codex session.
I am not presenting this as a security issue or as an officially supported feature.
I am mainly interested in two questions:
1. Is this orchestration pattern expected?
2. Is OpenAI considering a native way for ChatGPT to supervise and redirect long-running local Codex/Work tasks?
The use case seems strong: ChatGPT can act as the reasoning supervisor while Codex remains the local execution boundary.
Has anyone else experimented with this kind of ChatGPT Web ↔ local Codex multi-turn orchestration?
#Codex #ChatGPT #Agents #AgenticWorkflows #Windows #ComputerUse
For the “deterministic next instruction” step, what exactly does the executor accept, and what happens if the response is incomplete or invalid? That acceptance contract would be a useful detail for reproducing the loop.
In my current POC, the executor does not accept arbitrary natural-language output as an instruction.
I used a deliberately narrow acceptance contract:
- ChatGPT must return a single expected instruction format.
- The executor only continues if that exact pattern is present.
- The instruction is constrained to the already-authorized local scope.
- After execution, the executor sends a structured result back to the same ChatGPT conversation.
- ChatGPT then returns the next instruction.
For example, in one test the orchestration contract was essentially:
RESULT_A = OK → return exactly STEP_B: create ...
RESULT_B = OK → return exactly STEP_C: create ...
...
RESULT_D = OK → return exactly TEST: OK
If ChatGPT returned something incomplete, unexpected, or outside the expected contract, the executor should stop rather than guess.
So the loop was deterministic at the protocol level even though ChatGPT itself is the reasoning layer.
For a production version, I would make this stricter, probably using a small structured schema such as:
{"status":"continue","action":"write_file","path":"...","content":"..."}
with explicit validation, allowed actions/paths, stop conditions, and a human-approval path for anything outside scope.
In other words, the important part is not “let the executor obey whatever ChatGPT says”; it is “let ChatGPT choose the next step inside a very small validated contract.”