Windows: secondary Codex session spawns visible console windows for child executable calls

Summary

On Windows, a primary Codex terminal/session behaves normally, but a second Codex tab/session appears to launch child executable calls in separate visible console windows.

This is reproducible specifically in the secondary session. The primary session does not exhibit the behavior.

Environment

• Windows 11
• Codex running in terminal tabs
• Multiple Codex sessions open concurrently
• Windows Terminal used as the terminal host

Reproduction

1. Start a Codex session in one terminal tab.
2. Run normal work involving shell/tool calls (pwsh, git, gh, etc.).
3. Open a second terminal tab and start a second Codex session.
4. In the second session, run work that triggers shell/tool calls.
5. Observe that many child executable calls spawn their own visible console/terminal windows.

Actual behavior

• In the first/main Codex session, child commands execute without spawning visible external console windows.
• In the second Codex session, many executable calls open a separate visible terminal/console window.
• The windows typically show a successful exit, e.g.:

[process exited with code 0 (0x00000000)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

• Changing Windows Terminal's setting to close automatically on clean exit reduces the symptom from accumulated windows to a brief visible flicker, but the secondary-session child consoles are still being created and remain disruptive.

Expected behavior

Child executable calls in additional Codex sessions should behave like those in the primary session: remain attached to/contained within the existing terminal/PTY (or otherwise run hidden) rather than creating visible transient console windows.

Important differentiator

This does not happen in the main/first Codex tab. It appears tied specifically to running a second concurrent Codex session/tab.

That suggests this may involve secondary-session console/PTY inheritance or Windows process creation flags rather than a generic Windows shell configuration issue.

Impact

The behavior is especially disruptive for autonomous/agent-style workflows that execute many short-lived commands, since each subprocess can cause a visible window flash.

A screenshot is available showing multiple short-lived terminal windows created by the secondary session.

Start by tracing secondary-session console/PTY inheritance and Windows process creation flags for shell/tool calls such as pwsh, git, and gh. Compare child-process behavior between the primary and secondary sessions. Done means executable calls in additional sessions remain contained in the existing terminal or run hidden, without visible console windows.