Problem

When the gateway restarts (via config.patch, adding agents, or any SIGUSR1-triggered reload), all running ACP sessions are terminated because the ACP runtime processes are children of the gateway process.

This means any long-running ACP task (e.g., a Codex code review of 845 files taking 15-30+ minutes) gets killed if an unrelated config change triggers a gateway restart — even something as routine as adding a new agent binding.

Reproduction

1. Spawn an ACP session: sessions_spawn(runtime='acp', agentId='codex', task='...')
2. While the ACP task is running, trigger a gateway restart (e.g., config.patch to add a new agent)
3. The ACP process is killed, work is lost, and no error/completion event is emitted back to the parent session

Expected Behavior

ACP sessions should survive graceful gateway restarts (SIGUSR1 reloads). Options:

• Defer restart until active ACP sessions complete (the gateway already does this for embedded runs — the log shows config change requires gateway restart — deferring until 2 operation(s), 1 embedded run(s) complete)
• Detach ACP processes from the gateway process tree so they persist across restarts
• Re-attach ACP sessions after restart and resume result collection

Impact

• Users lose potentially expensive long-running work (Codex uses ChatGPT subscription tokens)
• No error is surfaced — the parent session has no idea the ACP task died
• Workaround: manually avoid gateway restarts while ACP is running, which is fragile and error-prone

Environment

• OpenClaw 2026.3.13
• ACP backend: acpx 0.1.16
• Agent: OpenAI Codex CLI 0.116.0
• macOS (Apple Silicon)

Logs

Gateway log shows it already defers for embedded runs but NOT for ACP sessions:

config change requires gateway restart (acp) — deferring until 2 operation(s), 1 embedded run(s) complete

The ACP session is not counted in this deferral check.