Headless agents can finish with accepted messages still unread · Issue #1512 · usestrix/strix · GitHub
Skip to content

Headless agents can finish with accepted messages still unread #1512

Open

Description

@guybass

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

  1. Start a non-interactive child through run_agent_loop, with a scripted Model.stream_response implementation.
  2. While its first response is in flight, call coordinator.send twice with synthetic instructions such as reassess before finishing.
  3. Return a normal work-tool call from that response.
  4. On the next turn, return an agent_finish call.
  5. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions