Turn completes prematurely when unified_exec background processes are still running #14731

What version of the Codex App are you using (From “About Codex” dialog)?

Latest from main branch (commit from codex-rs/core)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

When an agent starts a long-running process via unified_exec (e.g., uv run train.py, npm run build, or any command that takes more than a few seconds), the turn completes immediately after the model's response — without waiting for the process to finish. The agent never receives the process output.

Root cause identified in code:

In codex-rs/core/src/codex.rs, the ResponseEvent::Completed handler only checks has_pending_input():

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

This does not account for running processes in unified_exec_manager.process_store. When a process is started with exec_command and returns a process_id (indicating it's still running), the turn should not end until:

1. The process completes, OR
2. The agent explicitly acknowledges detachment

Observed behavior:

• Agent calls exec_command with a long-running command
• Process starts, returns process_id
• Model generates response text
• ResponseEvent::Completed fires
• has_pending_input() returns false
• Turn ends — agent loses opportunity to wait for output

What steps can reproduce the bug?

1. Start a Codex session
2. Ask the agent to run a long-running command:

   Run `sleep 30 && echo "done"` and tell me when it finishes
   

3. Observe that the turn ends immediately after the agent starts the command
4. The agent never reports "done" because it doesn't wait for the process

Alternative reproduction with training script:

Run `uv run train.py` and analyze the results when it completes

The agent starts the 5-minute training script but the turn ends within seconds.

Code path:

1. exec_command is called → process starts → process_id returned (process still running)
2. Model generates text response
3. ResponseEvent::Completed triggers
4. has_pending_input() → false (no tool responses queued)
5. needs_follow_up = false
6. Turn ends

What is the expected behavior?

When a unified_exec process started in the current turn is still running, the turn should NOT complete. Instead:

1. Codex should detect running processes via unified_exec_manager.process_store
2. Inject a warning message to the model (e.g., "A background terminal is still running...")
3. Set needs_follow_up = true to continue the turn
4. Allow the model to either:
   • Wait for the process (call write_stdin to poll)
   • Explicitly acknowledge detachment

This enables reliable execution of long-running commands and autonomous workflows.

Additional information

I have implemented a fix in branch raman/fix/turn-end-guard-running-processes, commit c2845da:

// In ResponseEvent::Completed handler:
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;
}

Files changed:

• 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, ProcessEntry accessible
• codex-rs/core/src/unified_exec/process.rs — made has_exited() pub(crate)
• codex-rs/core/src/codex_tests.rs — unit test
• codex-rs/core/src/unified_exec/mod_tests.rs — integration tests

All tests pass (3 new tests added).

Context: Discovered while working on autoresearch — autonomous AI research platform where agents run 5-minute training experiments. This bug makes autonomous experiment loops impossible.

I don't currently have PR access. Happy to provide the complete diff or adjust implementation based on maintainer feedback.