Windows: approved pytest run interrupts TUI and sends SIGINT to MCP servers

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #20443

Powered by Codex Action

Additional impact: this is not just a single-session annoyance. The user opened a fresh Codex terminal/window for the same project and hit the same interruption again, which effectively blocks continuing work on that project from Codex TUI. The main problem is that the TUI exits/interruption loses the working conversation instead of surfacing the pytest/sandbox error and allowing the agent to continue.

Additional reproduction with more focused evidence:

I reproduced this again from the Codex TUI by approving a direct elevated full pytest command:

python -m pytest --basetemp E:\tmp\codex-full-direct-probe -p no:cacheprovider -q

Relevant log sequence:

2026-05-03T16:29:37.810849Z ToolCall: shell_command {"command":"python -m pytest --basetemp E:\\tmp\\codex-full-direct-probe -p no:cacheprovider -q","workdir":"E:\\xiu\\biji\\novels\\opennovel","timeout_ms":120000,"sandbox_permissions":"require_escalated",...}
2026-05-03T16:29:43.482822Z submission_dispatch{otel.name="op.dispatch.exec_approval" ...}: new
2026-05-03T16:29:43.483738Z submission_dispatch{otel.name="op.dispatch.exec_approval" ...}: close
2026-05-03T16:29:47.861631Z MCP server stderr (cmd): [INFO] Received SIGINT, shutting down...
2026-05-03T16:30:09.668699Z thread_spawn: codex_core::session: new

No pytest result or exit code was returned to the conversation. Afterward the next turn logged:

codex_core::context_manager::normalize: Function call output is missing for call id: ...

This is useful because smaller probes behaved differently:

• A sandboxed minimal pytest using tmp_path failed normally with PermissionError: [WinError 5] Access denied and did not interrupt the session.
• The same minimal pytest passed when approved/elevated.
• codex exec with mcp_servers={} and with normal MCP enabled both completed a short python --version command successfully.
• A direct elevated full pytest from the active TUI is what reproduced the interruption.

So MCP receiving SIGINT appears to be a symptom of the Codex session/task being aborted or restarted, not necessarily the root cause. The failing path seems closer to: Windows TUI + approved/elevated long/full pytest command + missing tool output/session restart.

If you're able to repro this, please use /feedback to upload logs and session details, then post the session (thread) ID here.

Broader impact: this is not limited to this Python project. Many Windows development workflows require approved/elevated commands: full test suites, builds, dependency installs, browser/E2E tests, codegen, services, or commands that need access outside the sandbox. If the TUI can abort/restart during an approved command, those projects become hard to continue in Codex CLI. The current workaround would be to bypass sandbox/approvals entirely or run those commands outside Codex, but that defeats the purpose of the approval flow. The approval/escalation path should be reliable and should return command output/errors instead of interrupting the conversation.

The thread ID visible in the local Codex log for the reproduction is:\n\n ext\n019dee80-091c-70b1-9934-43bef820a158\n\n\nThe interruption happened in this same thread around the approved command shown above. I will also use /feedback from the TUI to upload logs/session details if possible.

Feedback has now been uploaded from the Codex TUI.

Uploaded thread:

019dee80-091c-70b1-9934-43bef820a158

Additional clarification after further testing:

This is not isolated to the main agent. I also tried asking a sub-agent from the Codex interactive TUI to run the same full pytest command. The result is the same: the entire Codex CLI TUI exits back to PowerShell.

So delegating the command to a sub-agent does not isolate or avoid the failure. Both main-agent and sub-agent shell tool calls appear to go through the same interactive TUI command execution / approval / child-process handling path, and that shared path is what fails.

I also tested the same full pytest command through codex exec on codex-cli 0.130.0, and it succeeds:

codex exec -C /e/xiu/biji/novels/opennovel -s danger-full-access --skip-git-repo-check "only run: python -m pytest tests -q"

256 passed in 4.00s

The same command also succeeds outside Codex TUI.

So the problem appears specific to the interactive Codex TUI path. The test suite and command are valid; Codex non-interactive exec can run it successfully. The failure is that the interactive TUI exits/interruption occurs when trying to run the full test workflow from the TUI, instead of keeping the session alive and returning stdout/stderr/exit code.

This is especially blocking for real project work because Codex cannot complete the normal coding loop:

1. edit code
2. run the full test suite
3. inspect failures
4. continue fixing

If the full test command exits the entire TUI, Codex loses the ability to validate and continue from the same conversation.

Update: I found the immediate trigger in my project.

The project used os.kill(pid, 0) as a Unix-style PID liveness check. On Windows, this is not a safe liveness check and can emit a console control event / interrupt the process. In my repro, pytest was effectively interrupted by the project code itself, which explains the KeyboardInterrupt after partial progress.

After replacing that code with a Windows-safe PID check using OpenProcess + GetExitCodeProcess, the same command now completes successfully inside Codex CLI:

python -m pytest tests -q

Result:

264 passed in 4.10s

So the original repro should not be treated as a pure Codex CLI bug.

That said, Claude Code did not terminate under the same project/test scenario, while Codex CLI did. This may still be useful as a Windows compatibility/isolation case: Codex CLI appears more vulnerable to child-process console control events affecting the TUI/session.

One more product-level clarification:

I understand now that the immediate trigger was a project-side Windows compatibility bug (os.kill(pid, 0)), so this should not be treated as a pure Codex bug.

However, the user-facing difference is still important: the same buggy project/test scenario did not terminate Claude Code, while Codex CLI lost/interrupted the interactive session. From a developer workflow perspective, that is a meaningful robustness gap.

Even when a child process or test suite misbehaves, the parent AI coding TUI ideally should isolate the failure, preserve the conversation, and return the command failure/output to the agent. If the whole TUI session is interrupted, the coding loop breaks:

1. edit code
2. run tests
3. inspect failure
4. continue fixing

This is especially noticeable because Claude Code appears to handle this kind of child-process/console-control failure more gracefully in the same environment. So while the project code was wrong, Codex could still improve its Windows TUI isolation/recovery behavior.

I am sharing this because I want Codex CLI to keep improving and become more robust in real Windows development workflows, especially for the full coding loop where agents need to run tests and continue from failures without losing the session.