Codex progress updates: why live status is not the final answer
Codex progress updates are evidence that a coding task is active. They are not the completed answer. When an agent sends a live status message and the host treats that message as final, the user can receive a believable but incomplete result: a plan, a note about work in progress, or a partial explanation with no authoritative terminal response.
OpenClaw’s v2026.7.1-1 release addresses this boundary for GPT/Codex app-server turns. After a delivered progress reply, the turn continues until Codex supplies its terminal response instead of being stopped mid-turn. The practical benefit is simple: status remains visible without replacing the result the user was waiting for.
Contents
- Why Codex progress updates can be mistaken for completion
- The difference between a progress event and a final response
- What changed in OpenClaw
- How to judge an agent run after a status message
- A safer completion contract for coding agents
- FAQ
Why Codex progress updates can be mistaken for completion
Long coding tasks need feedback. A user who sees nothing while an agent reads a repository, runs tests, or waits on a tool call has no way to distinguish useful work from a stalled process. Progress messages solve that visibility problem, but they also create a lifecycle problem: a transport can deliver a message before the model has completed the turn.
That distinction is especially important with app-server integrations. OpenAI documents codex app-server as an experimental local interface for development or debugging over stdio, WebSocket, or a Unix socket. The host application has to interpret a stream of events, including interim activity, and decide when the turn is actually done.
A progress update may say that Codex is inspecting a failure, applying a patch, or checking a command. None of those statements establish that the work succeeded. The terminal response is the authoritative completion signal because it is where the agent can report the result, name unresolved errors, or explain why it stopped.
The issue is not cosmetic. If a host ends a run on the first delivered status event, it can cut off the part of the turn that matters most: the final response that tells the operator what changed and what still needs attention. For an overview of how OpenClaw keeps sessions, tools, and channels coordinated, see how OpenClaw works.
The difference between a progress event and a final response
A reliable agent host needs separate states for activity, delivery, and completion. Folding all three into one boolean such as “responded” creates false success.
| Signal | What it means | What it should not mean |
|---|---|---|
| Progress update | The agent emitted useful interim activity | The task finished successfully |
| Delivered message | A channel accepted and showed an update | The model closed the current turn |
| Terminal response | The model supplied its final answer for the turn | Every external side effect is automatically verified |
| Verified outcome | The host checked the expected artifact, command result, or handoff | The agent will never need human review |
The table points to a useful operational rule: track the message lifecycle and the task lifecycle independently. A chat channel can be healthy while a task is still working. A task can complete while a delivery retry is pending. Treating either condition as the other leads to confusing failures.
This separation also makes incident review more honest. “We sent an update” is not a substitute for “the task completed.” If an agent is supposed to write code, its final status should identify the changed files, validation result, and any blocker. The same discipline applies to scheduled work. OpenClaw cron jobs are much easier to trust when their final delivery is tied to a verified output rather than a mid-run notification.
What changed in OpenClaw
The v2026.7.1-1 notes describe a focused fix: OpenClaw keeps Codex app-server turns running after delivered progress messages so GPT/Codex can reach its authoritative terminal response. The release cites pull requests #106961 and #108487.
This is a narrower claim than “Codex never stops early.” Networks, providers, tool calls, and local processes can still fail. The fix corrects one specific ownership boundary: a progress reply no longer tells OpenClaw that the underlying app-server turn has finished.
That boundary had already surfaced in public OpenClaw issue discussion. Issue #88331 describes an app-server turn that can emit reasoning or commentary progress without sending turn/completed, and distinguishes that case from a turn with no progress at all. That is exactly why a host needs to preserve a final-response path after visible activity.
The release follows a larger direction in v2026.7.1: connected coding-agent workflows, session continuity, workspace terminals, and recovery paths received broad work. The progress-reply correction is less visible than a new dashboard panel, but it protects the basic promise of a coding agent: a user gets the final answer, not a premature preview.
How to judge an agent run after a status message
When an agent sends an update such as “running tests” or “patch applied,” use the status as a cue to wait for the completion record. A good final record should answer these questions:
- Did the turn reach a terminal response?
- What files, configuration, or external artifacts changed?
- What validation actually ran, and did it pass?
- If something failed, is the error visible and is the next action clear?
For code changes, a link to a reviewable diff or pull request is stronger evidence than a prose claim. For a browser or API task, the final response should identify the completed action and the response that confirmed it. For a cron job, it should name the output location and delivery target.
The OpenClaw Control UI is useful here because it lets an operator keep task state close to the conversation. Still, an interface should display interim updates as interim. A green-looking chat message without a terminal outcome is a prompt to inspect the run, not an outcome to trust.
A safer completion contract for coding agents
If you build agent workflows around Codex or another streamed coding model, make completion explicit in the workflow contract.
- Emit progress only as a status signal. It may be useful to users, but it must not close the task.
- Preserve the provider’s terminal event as the source of truth for the turn.
- Attach proof to the final response: test output, a changed-file list, a PR URL, or a clear failure message.
- Give silent or stalled runs their own timeout path. A timeout is a failure classification, not a reason to reinterpret the last progress update as success.
- Keep human approval at the boundary where a result creates side effects. A final response can say that a change is ready; it does not make deployment or access changes safe by itself.
This approach does not require turning every status update into a verbose transcript. Short progress messages are useful. The key is that the UI and the host preserve their meaning. Progress says “still working.” A terminal response says “this is the result.” Verification says “the result was checked.”
FAQ
Are Codex progress updates the same as a completed task?
No. A progress update tells you that the agent produced interim activity. A completed task needs a terminal response from the model and, when the task changes something, evidence such as test output, an artifact, or a reviewable diff.
What did OpenClaw fix in v2026.7.1-1?
OpenClaw changed the Codex app-server flow so delivered progress replies do not stop the underlying GPT/Codex turn before it reaches its authoritative terminal response. The release notes list this as the Codex progress replies fix.
Should a coding-agent host wait forever after a progress message?
No. It should keep the final-response path open while using a distinct timeout policy for a genuinely stalled turn. A timeout should surface as an incomplete or failed run, rather than being disguised as a successful completion.
How can I verify that an AI coding task actually finished?
Look for the final response, then inspect the evidence appropriate to the task: changed files, a pull request, test output, command output, or a confirmed external action. Progress text alone is not sufficient evidence.