Question
Should a Codex worker session that has already reported agentReportedState: "completed" be treated as terminal/success before later process lifecycle probes can mark it stuck?
Context
We are testing AO with the Codex agent plugin on Windows using the local process runtime:
@aoagents/ao: 0.9.2
@aoagents/ao-plugin-agent-codex: 0.9.1
- Windows PowerShell
- Project agent configured as
codex
- Worker launched after locally patching
agent-codex to use codex exec for prompt-driven non-interactive work
This is separate from the agent-codex launch-command issue in #2078 / #2079.
Observed behavior
After the local codex exec patch, AO spawned session atp-2 and the Codex worker successfully performed the requested smoke task:
- created
ao-smoke-result.txt containing AO_SMOKE_OK
- ran the project tests successfully
- created branch
feat/ao-smoke-atp-2
The session JSON contained completion evidence:
{
"agentReportedState": "completed",
"agentReportedAt": "2026-06-01T11:23:06.685Z",
"codexThreadId": "019e82eb-3170-7891-bec0-2291b84ebe5e"
}
However, before manual cleanup, ao session ls --json later reported the session as stuck. The lifecycle evidence looked like:
reason: probe_failure
runtime state: exited
signal_disagreement runtime=alive process=dead activity_signal=valid via_native activity=exited
Attempting to report completion externally after that was rejected because the runtime had already exited:
Report rejected: runtime is not alive
Expected / question
For prompt-only local work where the worker has reported completed, should AO promote that session to a terminal completed state before runtime exit probes can escalate it to stuck?
Or is the current behavior expected because AO requires some other completion path, artifact, PR state, or runtime shutdown protocol in addition to agentReportedState: "completed"?
If this is expected behavior, guidance on the intended lifecycle contract for short-lived headless agents would be very helpful.
Question
Should a Codex worker session that has already reported
agentReportedState: "completed"be treated as terminal/success before later process lifecycle probes can mark itstuck?Context
We are testing AO with the Codex agent plugin on Windows using the local process runtime:
@aoagents/ao:0.9.2@aoagents/ao-plugin-agent-codex:0.9.1codexagent-codexto usecodex execfor prompt-driven non-interactive workThis is separate from the
agent-codexlaunch-command issue in #2078 / #2079.Observed behavior
After the local
codex execpatch, AO spawned sessionatp-2and the Codex worker successfully performed the requested smoke task:ao-smoke-result.txtcontainingAO_SMOKE_OKfeat/ao-smoke-atp-2The session JSON contained completion evidence:
{ "agentReportedState": "completed", "agentReportedAt": "2026-06-01T11:23:06.685Z", "codexThreadId": "019e82eb-3170-7891-bec0-2291b84ebe5e" }However, before manual cleanup,
ao session ls --jsonlater reported the session asstuck. The lifecycle evidence looked like:Attempting to report completion externally after that was rejected because the runtime had already exited:
Expected / question
For prompt-only local work where the worker has reported
completed, should AO promote that session to a terminal completed state before runtime exit probes can escalate it tostuck?Or is the current behavior expected because AO requires some other completion path, artifact, PR state, or runtime shutdown protocol in addition to
agentReportedState: "completed"?If this is expected behavior, guidance on the intended lifecycle contract for short-lived headless agents would be very helpful.