In-process task runner: spawning a new child cuts the running child's transport (transport_gone within 1-2s)

[code-yeongyu]

Summary

On the in-process task runner (a session running omo directly, not through the shared RPC daemon host), spawning a new child task terminates the child that is already running: the running child reports transport_gone 1-2 seconds after the new spawn. Children running on a shared daemon host coexist normally.

Reproduction

Observed 3/3 on a long-lived session (engine 0.0.0-omob.8fd4c01.cd317ee, ~5h uptime, in-process runner):

new spawn	running child dies
08:36:24	08:36:26
08:48:15	08:48:16
08:52:16	08:52:17

Same session, same day: children that had been placed on the shared daemon host (omo --mode rpc --multi-session) were not affected by later spawns.

Expected

Spawning a second child on the in-process runner leaves the first child running; both complete independently.

Actual

The first child's transport is torn down when the second is admitted. The parent records the first as lost; work in its worktree is orphaned.

Evidence

Evidence held locally (session ledger + notepad on a dev machine). Related but distinct from #8579 (oh-my-openagent: duplicate child sessions after a lost admission reply) and from #1905 (host stall -> peer cut): here the host is not stalled and the parent itself triggers the cut by spawning.

Scope / acceptance

• RED: in-process runner test that spawns child A, waits until it is running, spawns child B, asserts A is still running and completes.
• GREEN: both children complete; no transport_gone on A.
• Verify on the shared-host path as a regression guard (should already pass).

Workaround in use: limit the in-process runner to one concurrent child.

[code-yeongyu]

Evidence from the orchestrating session's task records (sanitized; machine and user identifiers removed). All times UTC, 2026-09-21.

Task-record timeline (.omo/senpi-task/tasks/st_*.json, fields started_at / updated_at / status / host_pid; "own-session" = the record's host_pid equals the orchestrator's own session process, i.e. the in-process fallback runner used while the public daemon socket was absent; "public daemon host" = host_pid null):

started (UTC)	ended (UTC)	child	final status	runner
07:27:40	08:12:17	todo-9	error	public daemon host
07:27:56	07:57:56	todo-11	completed	public daemon host
07:28:13	07:57:18	todo-15	completed	public daemon host
07:35:40	07:58:29	todo-11-2	completed	public daemon host
07:38:32	07:38:53	todo-16	error	own-session (in-process fallback)
07:40:38	08:12:17	todo-16-2	completed	public daemon host
07:46:16	08:30:31	todo-9-2	completed	own-session (in-process fallback)
07:54:14	08:27:17	todo-14	completed	public daemon host
07:54:57	08:27:18	review-11	completed	public daemon host
08:09:43	08:42:17	todo-13	completed	public daemon host
08:22:06	08:36:26	todo-8	error	own-session (in-process fallback)
08:36:24	08:48:16	todo-10	error	own-session (in-process fallback)
08:38:26	08:44:58	todo-8-2	error	own-session (in-process fallback)
08:48:15	08:52:17	todo-8-3	error	own-session (in-process fallback)
08:52:16	08:52:16	todo-10-2	running	own-session (in-process fallback)

Eviction pairs (new spawn -> running child dies 1-2 s later, all on the own-session runner):

• todo-10 started 08:36:24 -> todo-8 error at 08:36:26
• todo-8-3 started 08:48:15 -> todo-10 error at 08:48:16
• todo-10-2 started 08:52:16 -> todo-8-3 error at 08:52:17

Non-matching case: todo-8-2 ended 08:44:58 with "The operation was aborted." and no spawn within its window (a steer message had been delivered to it at start); listed for completeness, not attributed.

Control: the seven children that ran between 07:27 and 08:42 on the public daemon host (host_pid null) overlapped freely (up to three concurrent) with no transport_gone, including two that were started while others ran.

DAG node error records (.omo/senpi-task/dag/runs/*.json):

• occupancy-diet-wave1-20260921 / todo-4 -> transport_gone at 05:03:26
• occupancy-diet-wave1-20260921 / todo-3 -> transport_gone at 05:03:27
• occupancy-diet-wave1-20260921 / todo-5 -> transport_gone at 05:03:28
• occupancy-diet-wave1-20260921 / todo-6 -> transport_gone at 05:03:28
• occupancy-diet-wave1-20260921 / todo-7 -> transport_gone at 05:04:22
• occupancy-diet-wave1-lanes-20260921 / todo-7 -> transport_gone at 05:18:45
• occupancy-diet-wave1-lanes-20260921 / todo-3 -> transport_gone at 05:18:46
• occupancy-diet-wave1-lanes-20260921 / todo-5 -> transport_gone at 05:18:46
• occupancy-diet-wave1-lanes-v2-20260921 / todo-6 -> transport_gone at 05:57:28
• occupancy-diet-wave1-lanes-v2-20260921 / review-5 -> transport_gone at 06:04:44
• occupancy-diet-todo-9-20260921 / todo-9 -> transport_gone at 07:43:17
• occupancy-diet-todo-8-20260921 / todo-8 -> transport_gone at 08:36:26
• occupancy-diet-todo-8-v2-20260921 / todo-8 -> The operation was aborted. at 08:44:58
• occupancy-diet-todo-10-20260921 / todo-10 -> transport_gone at 08:48:17
• occupancy-diet-todo-8-v3-20260921 / todo-8 -> transport_gone at 08:52:17

The orchestrator's binary during the whole window was the older build (0.0.0-omob.8fd4c01); it has since kept to one child at a time on that runner. Distinct from the ghost-session/respawn pattern (#8579) - here the evicted child is the OLDER one and dies immediately on the newer one's start - and from the host memory-admission work in #1905.