Bug
The headless CLI server does not write session.idle to events.jsonl when the original subscriber has disconnected, even though the session completes successfully. This affects two scenarios:
Scenario 1: Subscriber disconnects during subagent execution
Steps:
- Connect to headless server, send prompt that spawns background subagents
- Disconnect subscriber (SIGTERM the client process) while subagents are running
- Wait for subagents to complete on the headless server
Expected: session.idle written to events.jsonl after final assistant.turn_end
Actual: File ends at assistant.turn_end — session.idle is never written
Evidence (session 2922c6af):
15:57:02 subagent.started (task)
15:57:02 subagent.started (task)
15:57:06 assistant.turn_end <- subscriber disconnected after this
15:58:07 subagent.completed (task) <- Agent 1 done (server kept running!)
15:58:08 subagent.completed (task) <- Agent 2 done
15:58:24 assistant.message "Both agents completed successfully"
15:58:24 assistant.turn_end <- LAST EVENT IN FILE
session.idle <- NEVER WRITTEN
Key observation: The headless server correctly keeps subagents running after disconnect and writes all intermediate events (subagent.completed, assistant.message, assistant.turn_end). Only session.idle is missing.
Scenario 2: session.idle emitted live but not written to disk
Even with an active subscriber, session.idle is sometimes emitted over the live event stream but not written to events.jsonl.
Evidence (session 4c8a75d4):
Live event diagnostics (received via SDK):
14:00:35.055 [EVT] received AssistantTurnEndEvent
14:00:35.099 [EVT] received SessionIdleEvent <- SDK received this!
14:00:35.248 [IDLE] CompleteResponse dispatched <- App processed it
events.jsonl on disk:
14:00:35.049 assistant.message
14:00:35.050 assistant.turn_end <- LAST LINE. No session.idle.
The SDK event stream delivered SessionIdleEvent and the app handled it. But the CLI never wrote session.idle to events.jsonl.
Impact
Any tool that reads events.jsonl to determine session state cannot detect session completion. This causes:
- PolyPilot (macOS/iOS/Android GUI): After app restart, sessions that completed while the app was down appear stuck for ~600s until a watchdog timeout fires. Multi-agent orchestration stalls because worker completion cannot be detected.
- Any headless automation: Scripts reading
events.jsonl to poll for completion will hang indefinitely.
Environment
- copilot CLI 1.0.16-1
- Headless mode:
copilot --headless --port 4321
- macOS 26.3.1 (arm64), Node v25.8.2
Workaround
PolyPilot uses a 600s watchdog timeout to detect stuck sessions, but this causes significant UX delays for multi-agent workflows.
Related
Bug
The headless CLI server does not write
session.idletoevents.jsonlwhen the original subscriber has disconnected, even though the session completes successfully. This affects two scenarios:Scenario 1: Subscriber disconnects during subagent execution
Steps:
Expected:
session.idlewritten toevents.jsonlafter finalassistant.turn_endActual: File ends at
assistant.turn_end—session.idleis never writtenEvidence (session
2922c6af):Key observation: The headless server correctly keeps subagents running after disconnect and writes all intermediate events (
subagent.completed,assistant.message,assistant.turn_end). Onlysession.idleis missing.Scenario 2: session.idle emitted live but not written to disk
Even with an active subscriber,
session.idleis sometimes emitted over the live event stream but not written toevents.jsonl.Evidence (session
4c8a75d4):Live event diagnostics (received via SDK):
events.jsonl on disk:
The SDK event stream delivered
SessionIdleEventand the app handled it. But the CLI never wrotesession.idletoevents.jsonl.Impact
Any tool that reads
events.jsonlto determine session state cannot detect session completion. This causes:events.jsonlto poll for completion will hang indefinitely.Environment
copilot --headless --port 4321Workaround
PolyPilot uses a 600s watchdog timeout to detect stuck sessions, but this causes significant UX delays for multi-agent workflows.
Related