Problem
A Codex First Officer can answer a captain's report, status, or why request with a final response while an async worker is still active. That ends the turn without reinstalling wait_agent, so worker completion is not processed until another captain message arrives.
This has happened repeatedly during real workflow drives.
The current Codex adapter says that the FO must resume monitoring when it becomes idle again, but it does not explicitly state that a status-style request is non-terminal or forbid a final response after the answer.
Proposed contract change
Add a runtime-neutral invariant under skills/first-officer/references/first-officer-shared-core.md:
A status, report, or explanation request does not alter active scope or create a stopping condition unless the captain explicitly pauses, stops, cancels, or replaces the work.
Add the Codex enforcement under skills/first-officer/references/codex-first-officer-runtime.md, near ## Codex wait notes or ## Captain Interaction:
When a worker remains active and unresolved, answer status-style questions in commentary, route newly authorized work, and call wait_agent(timeout_ms: 300000) in the same turn once idle. Do not send a final response solely because the question was answered.
Acceptance
- A live or fixture-backed Codex drive starts an async worker.
- A captain sends
report, status, or why before completion.
- The FO answers and resumes the wait loop in the same turn without another captain message.
- The completion signal is verified and routed normally.
- Explicit pause, stop, cancel, or replacement still ends or redirects monitoring.
- Claude and Pi behavior does not regress.
Do not prove this with a prose-presence test. Exercise the runtime behavior or a fixture whose oracle is the observed wait/tool sequence.
Problem
A Codex First Officer can answer a captain's
report,status, orwhyrequest with a final response while an async worker is still active. That ends the turn without reinstallingwait_agent, so worker completion is not processed until another captain message arrives.This has happened repeatedly during real workflow drives.
The current Codex adapter says that the FO must resume monitoring when it becomes idle again, but it does not explicitly state that a status-style request is non-terminal or forbid a final response after the answer.
Proposed contract change
Add a runtime-neutral invariant under
skills/first-officer/references/first-officer-shared-core.md:Add the Codex enforcement under
skills/first-officer/references/codex-first-officer-runtime.md, near## Codex wait notesor## Captain Interaction:Acceptance
report,status, orwhybefore completion.Do not prove this with a prose-presence test. Exercise the runtime behavior or a fixture whose oracle is the observed wait/tool sequence.