Describe the feature or problem you'd like to solve
Project-session coordination APIs do not expose whether a child session is actively processing or still has queued user messages. A parent can receive a completion handoff and see static branch/diff metadata from get_session, yet remain unable to prove the child is drained before merging its pull request.
This creates a cross-session merge race: if the parent previously sent a follow-up that is still queued, the child can wake after the parent merges, process that message, and push a trailing commit to the already-merged branch.
Proposed solution
Expose explicit processing and queue state in get_session and list_sessions_and_chats, for example:
is_processing: booleanqueued_messages_count: number- the current/last processed message identifier or a monotonic drain generation
Provide a native way for a coordinator to establish a merge barrier: wait until the child reports no active turn and no queued messages, then send a final stop/ready request and verify its acknowledgment belongs to the latest queue generation.
This would make project-session orchestration safe without relying only on conversational conventions or guessing from updated_at.
Example prompts or workflows
- A parent asks a child to implement a PR, sends two review fixes, then checks
is_processing == false and queued_messages_count == 0 before merging.
- A parent sends “Make no further changes; reply READY_FOR_MERGE,” then verifies the reply drained the latest queue generation before running
gh pr merge.
- An orchestration dashboard shows which child sessions are idle, actively processing, or waiting on queued input.
- A parent avoids archiving a child that still has pending messages even though its latest task handoff is complete.
Additional context
Observed workflow: a child reported a validated PR head; the parent independently reviewed and merged it. A previously queued follow-up then woke the child, which produced and pushed a test-only commit after merge. The child detected the race and stopped, but the parent had no API field that could have prevented it.
Related queue/session-state reports do not expose a coordinator merge barrier:
Describe the feature or problem you'd like to solve
Project-session coordination APIs do not expose whether a child session is actively processing or still has queued user messages. A parent can receive a completion handoff and see static branch/diff metadata from
get_session, yet remain unable to prove the child is drained before merging its pull request.This creates a cross-session merge race: if the parent previously sent a follow-up that is still queued, the child can wake after the parent merges, process that message, and push a trailing commit to the already-merged branch.
Proposed solution
Expose explicit processing and queue state in
get_sessionandlist_sessions_and_chats, for example:is_processing: booleanqueued_messages_count: numberProvide a native way for a coordinator to establish a merge barrier: wait until the child reports no active turn and no queued messages, then send a final stop/ready request and verify its acknowledgment belongs to the latest queue generation.
This would make project-session orchestration safe without relying only on conversational conventions or guessing from
updated_at.Example prompts or workflows
is_processing == falseandqueued_messages_count == 0before merging.gh pr merge.Additional context
Observed workflow: a child reported a validated PR head; the parent independently reviewed and merged it. A previously queued follow-up then woke the child, which produced and pushed a test-only commit after merge. The child detected the race and stopped, but the parent had no API field that could have prevented it.
Related queue/session-state reports do not expose a coordinator merge barrier: