Proof for this fix:

• repo-native validation passed twice:
  • pnpm exec oxfmt --check src/agents/acp-spawn-parent-stream.ts src/agents/acp-spawn-parent-stream.test.ts
  • pnpm exec oxlint --type-aware src/agents/acp-spawn-parent-stream.ts src/agents/acp-spawn-parent-stream.test.ts
  • pnpm exec vitest --run src/agents/acp-spawn-parent-stream.test.ts src/agents/acp-spawn.test.ts (run twice)
• filesystem-backed runtime proof exercised the failure mode from this issue: the parent relay received no child lifecycle events on the local in-memory bus, and still emitted terminal notices from persisted ACP session state
• observed terminal events:
  • codex run completed.
  • codex run failed: provider disconnected
• text artifacts (summary/json/log): https://gist.github.com/giulio-leone/7cf86f5bc3ad72acf7763440ebfa9fde

I also generated local PNG/MP4 proof artifacts from the same run; GitHub CLI/gist can publish the text artifacts directly, but binary attachment upload is not available from this CLI path.

Greptile Summary

This PR fixes a production reliability issue where parent relays for ACP children that completed in a different gateway process would stall indefinitely — never receiving the terminal lifecycle event from the local in-memory event bus — and only time out after the 6-hour maxRelayLifetimeMs deadline. The fix adds a filesystem-backed persisted-state polling fallback inside the existing noOutputWatcherTimer interval, with carefully guarded anti-false-positive conditions.

Key changes:

• Adds readPersistedAcpRelayState() helper that reads readAcpSessionEntry and normalises the ACP state, with full error containment via try/catch.
• In noOutputWatcherTimer, polls persisted ACP state on every tick and emits a terminal done:persisted or error:persisted event when the child session key transitions through running → idle or running → error in the persisted store.
• Guards stale pre-run idle state via persistedActivityAt >= relayStartedAt (timestamp fence) and a sawPersistedRunningState flag, preventing false-positive completions from a previous run's residual state.
• Adds three targeted regression tests covering persisted idle, persisted error, and stale pre-run idle guard.

Confidence Score: 5/5

• PR is safe to merge — the fix is well-scoped, logic is sound, and new tests cover all three new code paths.
• No correctness bugs found. The timestamp fence (persistedActivityAt >= relayStartedAt) and the sawPersistedRunningState flag together correctly prevent false positives from stale pre-run idle/error states. The try/catch in readPersistedAcpRelayState ensures file I/O errors never break relay flow. The dispose() idempotency guard prevents double-emit races between the event bus path and the new persisted-state path. All three new test scenarios validate exactly the cases described in the PR description.
• No files require special attention.

_{Reviews (1): Last reviewed commit: "Fix ACP parent completion relay" | Re-trigger Greptile}

Maintainer-ready status update: the bot feedback on this PR has already been absorbed in the current branch state, the PR is CLEAN/mergeable, and the current check suite is green across the matrix (including Windows shards). No further contributor-side changes are pending from my side.

Contributor-side this PR looks ready to merge: merge state is CLEAN, visible checks are green, the diff stays narrowly scoped to the ACP parent completion relay implementation/tests, and my attempt to enable auto-merge was blocked only by missing MergePullRequest permission. I do not see a remaining contributor-side blocker here.

Re-checked against current origin/main on 2026-03-29. This one still looks live. acp-spawn-parent-stream.ts still appears to rely on the local in-memory onAgentEvent() bus without a persisted-state fallback, so the cross-process parent completion gap is still plausible on current main.

This is currently my leading candidate for the cross-process fallback side of the ACP relay family.

Closing as not merge-ready. Re-reviewing the current branch against the latest comments shows a real data-model gap, not a small condition bug: the persisted fallback is session-scoped, but correctness here needs a run-scoped persisted marker (for example currentRunId, lastCompletedRunId, or a persisted run-start timestamp tied to this relay). Without that, we are stuck between two bad choices: trust session-level terminal state too easily and complete the wrong run, or require a polled running transition and miss short runs entirely. The safer next step is a fresh narrower change that first persists a run-scoped ACP marker, then a follow-up relay patch that consumes it. Thanks for the investigation and for narrowing the cross-process completion failure mode.