You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Headless agents can finish with accepted messages still unread #1512
Headless agents can accept peer messages, continue making model calls without those messages in their input, and successfully call agent_finish while their inbox is still nonempty.
This report is based on a deterministic offline reproduction against upstream main f7a32ae, using the real SDK runner and a scripted model. It contains no scan logs, target source, credentials, or vulnerability details.
Reproduction
Start a non-interactive child through run_agent_loop, with a scripted Model.stream_response implementation.
While its first response is in flight, call coordinator.send twice with synthetic instructions such as reassess before finishing.
Return a normal work-tool call from that response.
On the next turn, return an agent_finish call.
Inspect the second model input and the final coordinator mailbox.
Actual: the second request omits the instructions, agent_finish succeeds, and the messages remain unread. The regression reproduces with SQLite and with no session. The send tool describes acceptance as delivery_status: "delivered".
Expected: accepted instructions reach a subsequent model-input boundary, and successful completion cannot strand pending messages. Acceptance should be reported as queued, without implying the model has read or acted on the message.
Implementation path
_run_agent_loop enables message interruption only for interactive runs. The headless SDK run can execute several model/tool turns without calling consume_pending. agent_finish does not check pending messages before completing.
A focused fix can checkpoint the mailbox between model calls, reload the persisted conversation without replaying completed tools or resetting the turn allowance, and serialize completion with message acceptance. Child completion and its parent notification also need to be published together so the parent cannot finalize in between them.
Related: #1107 and #1161 cover messages lost on failed persistence. This issue also reproduces when session writes never fail; safe persistence is needed for the new delivery checkpoint too.
Environment: Linux, Python 3.12.14, Strix 1.7.0, locked openai-agents 0.19.0. Tests use a scripted local model with network access disabled; no LLM requests or security scans are required. AI assisted the implementation and tests. A PR with the offline regression follows.
Activity