Repository navigation
agent_send reply mishandles parallel and chain background lanes #183
Description
What happened?
agent_send replies do not behave correctly for multi-task background lanes.
For a completed parallel or chain lane, reply restarts the lane with the original tasks/chain still present, so the new reply prompt is ignored by mode selection and the original work runs again. For a running parallel lane, reply only targets the base sessionId, so sibling child sessions such as sessionId-1 do not receive it.
This conflicts with the documented agent_send behavior that replies continue the lane's existing transcript. I reproduced both cases on clean main @ adcf37b in core subagent tests, without external extensions. I have a local fix and regression tests ready and would like to submit a PR.
Steps to reproduce
- Start a background parallel lane:
{ "tasks": [ { "agent": "general", "task": "A" }, { "agent": "general", "task": "B" } ], "run_in_background": true, "alias": "lane" } - Wait for it to complete.
- Send
agent_sendwithaction: "reply"and promptC. - The original A/B tasks run again; C is not delivered as the new turn.
- The same completed-lane behavior reproduces with
chain. - While a parallel lane is still running, a reply reaches the base child but not sibling
sessionId-Nchildren.
Expected behavior
A reply should continue the existing lane transcript with the new prompt, preserve the lane topology, and not silently rerun the original prompt. Running parallel replies should not be delivered to only part of the lane.
Version
main @ adcf37b / @step-harness/coding-agent 0.84.4
Activity
xuxujo97-coder commentedon Sep 28, 2026
Verification (against current
main)packages/coding-agent/src/features/subagent/lane-lifecycle.ts:289-290(replyToLane), with live lanes keyed in the same registry — both symptoms (completed parallel/chain lanes restarting with the originaltasks/chainso the reply prompt is ignored; running-lane replies hitting only the basesessionIdinstead of siblingsessionId-1) sit exactly in that routing.Please open the PR with the regression tests — this is a correctness fix for documented behavior.
quifox commentedon Sep 28, 2026
@IRemover I have the fix and regression tests ready, but PR creation is currently restricted. Could you add me to the external contributor whitelist when it opens? I can submit it once access is available.
liuedcson commentedon Oct 23, 2026
Thanks for the precise report — both symptoms (completed lanes rerunning the original batch, and running parallel replies reaching only the base
sessionId) were easy to confirm once pointed at the reply routing, and the repro steps were helpful.This has been fixed in #282 (
118348c0).agent_send replynow applies only to single-agent lanes:tasks/chain, so the new prompt is never silently dropped and the batch is never rerun;sessionId/sessionId-N.Coverage in
packages/coding-agent/test/step-subagent-events.test.ts:reply is refused for parallel and chain lanes without rerunning the batcha single-lane reply runs only the follow-up task for the lane's agent34 tests pass on current main (
a749d471).One thing to flag so expectations are clear: follow-up prompts to parallel/chain lanes remain unsupported by design — the recommended path is a new subagent call with the follow-up task. If topology-preserving multi-agent follow-ups turn out to matter to real workflows, please open a focused feature request and we will evaluate it properly.
Closing as fixed — thanks again for the clear write-up.