write_stdin dispatch is not gated on exec session stdin liveness

What version of Codex CLI is running?

0.121.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Windows Terminal (WSL)

What issue are you seeing?

### Description

Im facing a repeated codex_core::tools::router errors where Codex attempted to write to stdin for an exec session that was already closed.

Examples:

error=write_stdin failed: stdin is closed for this session; rerun exec_command with tty=true to keep stdin open


session_id: 21054
command: git log ...
result: exit_code=0, completed
next call: write_stdin {"chars":"\^C"}
error: stdin is closed

session_id: 85257
command: curl -I --max-time 10 http://127.0.0.1:8082/
result: timeout, exit_code=28
next call: write_stdin {"chars":"\^C"}
error: stdin is closed

This looks like a session lifecycle/state-check issue rather than a user command failure. The router or caller appears to dispatch an interrupt without first confirming that the exec session is still live and stdin-writable.

Expected behavior:

• If the exec session has already exited, the interrupt should be skipped or treated as a no-op.
• The router should avoid emitting an ERROR for an expected closed-session race.
• The caller should check session liveness/stdin-open state before dispatching write_stdin.

Actual behavior:

• Codex attempts write_stdin with Ctrl-C against a closed exec session.
• The router logs an ERROR from core/src/tools/router.rs:212.

Impact

This appears recoverable, but it can interrupt workflows involving interactive commands or long-running terminal

Additional information

What steps can reproduce the bug?

1. Run a command that Codex tracks as an exec session:

git log --oneline --decorate --graph --max-count=40 -- <some-files>


1. Let the command complete successfully.

Observed result:

exit_code=0
status=completed

1. Codex then attempts to interrupt the same session:

     {
       "chars": "\^C"
     }

1. The router emits the error because stdin is already closed.

What is the expected behavior?

-If the exec session has already exited, the interrupt should be skipped or treated as a no-op.
-The router should avoid emitting an ERROR for an expected closed-session race.
-The caller should check session liveness/stdin-open state before dispatching write_stdin.

Additional information

_No response_