Turn-End Guard: Prevent premature turn completion when unified_exec processes are still running

[morozow]

Summary

I'd like to propose a fix that prevents Codex turns from completing prematurely when background unified_exec processes (started via exec_command) are still running. This is critical for workflows involving long-running commands like training scripts, build processes, or any command that takes more than a few seconds.

Problem Statement

When an agent starts a long-running process through unified_exec (e.g., uv run train.py), the turn can end immediately after the model's response completes, even though the process is still running in the background. The agent loses the opportunity to wait for results and continue working with the output.

Current behavior:

1. Agent calls exec_command with a long-running command
2. Process starts, returns process_id (indicating it's still running)
3. Model generates response text
4. ResponseEvent::Completed fires
5. has_pending_input() returns false (no tool responses queued)
6. Turn ends — agent never sees the process output

Expected behavior:

• Turn should not end while processes started in that turn are still running
• Agent should be prompted to either wait for the process or explicitly detach

Root Cause

In codex-rs/core/src/codex.rs, the turn completion logic only checks has_pending_input():

ResponseEvent::Completed { .. } => {
    // ...
    needs_follow_up |= sess.has_pending_input().await;
    // Turn ends if needs_follow_up is false
}

This doesn't account for running unified_exec processes stored in unified_exec_manager.process_store.

Proposed Solution

Add a check for running unified_exec processes before allowing turn completion:

// Check for running unified_exec processes started in this turn.
// If there are running processes, inject a warning and force follow-up
// to prevent the turn from ending while background processes are still running.
if !needs_follow_up && sess.has_running_unified_exec_processes(&turn_context).await {
    sess.record_model_warning(
        "A background terminal started in this turn is still running. \
        If you intend to keep waiting for it, call write_stdin on the existing \
        process_id instead of ending the turn. If you are intentionally done \
        waiting, explicitly say that you are detaching from the background process.",
        &turn_context,
    ).await;
    needs_follow_up = true;
}

The has_running_unified_exec_processes method checks if any process in the store:

1. Was started during the current turn (by matching call_id prefix with turn_context.sub_id)
2. Has not yet exited

Implementation Details

Files changed:

File	Change
codex-rs/core/src/codex.rs	Added has_running_unified_exec_processes() method; modified ResponseEvent::Completed handling
codex-rs/core/src/unified_exec/mod.rs	Made process_store, processes, ProcessEntry, and has_exited() accessible
codex-rs/core/src/unified_exec/process.rs	Made has_exited() method pub(crate)
codex-rs/core/src/codex_tests.rs	Added unit test
codex-rs/core/src/unified_exec/mod_tests.rs	Added integration tests

New method signature:

impl Session {
    pub async fn has_running_unified_exec_processes(&self, turn_context: &TurnContext) -> bool
}

Tests added:

• has_running_unified_exec_processes_returns_false_when_no_processes
• has_running_unified_exec_processes_detects_running_process
• has_running_unified_exec_processes_ignores_completed_commands

All tests pass.

Context: Why This Matters

I encountered this issue while working on autoresearch – an autonomous AI research platform where agents run 5-minute training experiments (uv run train.py) and iterate on results. Without this fix, the agent's turn ends seconds after starting the training script, making autonomous experimentation impossible.

This fix enables:

• Reliable execution of long-running commands
• Autonomous workflows that depend on command output
• Proper agent-process lifecycle management

Request

I have a working implementation with tests ready. Since public PR access appears to be restricted, I'm requesting:

1. Feedback on the proposed approach
2. Guidance on how to contribute this fix (PR access, or if maintainers prefer to implement it based on this spec)

I'm happy to provide the complete diff, answer questions, or adjust the implementation based on maintainer feedback.