Environment: codeg v0.28.0 (reproduced after updating today; also seen on the prior build), Windows 11. Parent agent: Claude Code. Delegation via the codeg MCP (delegate_to_agent / get_delegation_status).
Minimal repro
delegate_to_agent(agent_type: "grok", task: "Health check. Reply with exactly the single word: DONE. Nothing else, no tools, no file edits.")- The child conversation renders the full reply within seconds.
get_delegation_status with wait_ms: 60000 keeps returning status: "running" with Latest sub-agent reply: DONE, indefinitely. It never becomes completed.
Control: the byte-identical task delegated to codex completes normally (status: "completed", duration_ms: 52468, text: "DONE"). So the delegation surface and status plumbing are fine in general; it is specifically the Grok child path that never terminalizes.
Evidence the child actually finished
get_session_info on the Grok child conversation, taken while the task still reported running:
message_count: 2, with the assistant's complete final text present- session
status: "in_progress", updated_at only ~0.8s after created_at
So the child's final message is persisted almost immediately, but the child session never leaves in_progress and the delegation report never flips. src-tauri/src/acp/delegation/meta_writer.rs documents that status: "completed" is written in complete_call, when the child's prompt round-trip resolves. The behavior is consistent with the Grok ACP child's session/prompt request never resolving even though every session/update chunk (including the full final message) was delivered, so complete_call never runs. I could not tell from the outside whether Grok's ACP hosting fails to send the prompt response for delegation children or the response is dropped on the codeg side.
Real-world impact
Two long Grok research delegations earlier today each finished and rendered their complete final answers in the child chat, while get_delegation_status sat on running with a frozen latest-reply snippet for 40+ minutes. The orchestrating parent, following the tool contract, concluded they were wedged and cancelled completed work. wait_ms: 0 blocks until the MCP client's idle timeout aborts the call. Today's tally: 3 of 3 Grok delegations reproduced this; 1 of 1 Codex delegation completed fine.
Related: #440 (background task indicator stuck after cancelling a delegated task), #428 and #447 (child states invisible to the parent; the permission case of the same blindness).
Happy to test a patch.
Environment: codeg v0.28.0 (reproduced after updating today; also seen on the prior build), Windows 11. Parent agent: Claude Code. Delegation via the codeg MCP (
delegate_to_agent/get_delegation_status).Minimal repro
delegate_to_agent(agent_type: "grok", task: "Health check. Reply with exactly the single word: DONE. Nothing else, no tools, no file edits.")get_delegation_statuswithwait_ms: 60000keeps returningstatus: "running"withLatest sub-agent reply: DONE, indefinitely. It never becomescompleted.Control: the byte-identical task delegated to
codexcompletes normally (status: "completed",duration_ms: 52468,text: "DONE"). So the delegation surface and status plumbing are fine in general; it is specifically the Grok child path that never terminalizes.Evidence the child actually finished
get_session_infoon the Grok child conversation, taken while the task still reported running:message_count: 2, with the assistant's complete final text presentstatus: "in_progress",updated_atonly ~0.8s aftercreated_atSo the child's final message is persisted almost immediately, but the child session never leaves
in_progressand the delegation report never flips.src-tauri/src/acp/delegation/meta_writer.rsdocuments thatstatus: "completed"is written incomplete_call, when the child's prompt round-trip resolves. The behavior is consistent with the Grok ACP child'ssession/promptrequest never resolving even though everysession/updatechunk (including the full final message) was delivered, socomplete_callnever runs. I could not tell from the outside whether Grok's ACP hosting fails to send the prompt response for delegation children or the response is dropped on the codeg side.Real-world impact
Two long Grok research delegations earlier today each finished and rendered their complete final answers in the child chat, while
get_delegation_statussat onrunningwith a frozen latest-reply snippet for 40+ minutes. The orchestrating parent, following the tool contract, concluded they were wedged and cancelled completed work.wait_ms: 0blocks until the MCP client's idle timeout aborts the call. Today's tally: 3 of 3 Grok delegations reproduced this; 1 of 1 Codex delegation completed fine.Related: #440 (background task indicator stuck after cancelling a delegated task), #428 and #447 (child states invisible to the parent; the permission case of the same blindness).
Happy to test a patch.