AI how-to notes · 2026-09-17 · last run 2026-09-17 · 한국어 원문

codex exec hangs at "Reading additional input from stdin..." — Windows field test

One line summary

Run codex exec "your prompt" from a script or from an AI agent's background shell and it can print Reading additional input from stdin... and go no further. When stdin is still attached to a pipe, codex waits for that input to finish. In our runs it exited normally as soon as we closed stdin with < /dev/null, or piped the prompt in and passed -.

Symptom

The screen or the log stops at a single line: Reading additional input from stdin....
No error explanation follows. We had a 60-second limit in place, so the run was killed at the limit and ended with exit code 124. The output file was empty.
On September 17 this happened when we passed the prompt to codex exec as an argument from Claude Code's background shell. The output file was 0 bytes and the last line of the log was Reading additional input from stdin.... We cancelled the job and ran it again with the prompt on stdin instead (fix 2 below), and it finished with exit code 0.

Why it happens

The answer is in the [PROMPT] description of codex exec --help.

[PROMPT]
  Initial instructions for the agent. If not provided as an argument (or if `-` is used),
  instructions are read from stdin. If stdin is piped and a prompt is also provided, stdin
  is appended as a `<stdin>` block

Even when the prompt is given as an argument, if stdin is connected to a pipe codex reads it so it can append the contents as a <stdin> block. If the other end of that pipe never closes, the read never ends.

Test environment

Item	Value
OS	Windows 11 Home (10.0.26200)
Shells	Git Bash, PowerShell 7.6.6
codex	`codex-cli 0.153.4`
Prompt	`Reply with the single word OK.` (identical in every condition)
Shared options	`--skip-git-repo-check -s read-only`

Six conditions we ran

Condition	Shell	State of stdin	Result	Time
A	Git Bash	Pipe held open for 90 seconds (`sleep 90 \|`)	Killed at the 60-second limit (exit code 124), output file empty	60s
B	Git Bash	Closed (`< /dev/null`)	Exit code 0, `OK`	7s
C	Git Bash	Prompt piped in with `-` (`echo "…" \| codex exec … -`)	Exit code 0, `OK`	not measured
D	Git Bash	Pipe that closes after 15 seconds (`sleep 15 \|`)	Exit code 0, `OK`	20s
E	PowerShell 7	Attached to the null device	Exit code 0, `OK`	8s
F	PowerShell 7	One string piped in, then the pipe ends	Exit code 0, `OK`	7s

In D the input does not close until the sleep 15 in front of the pipe finishes, and the whole run took 20 seconds and exited normally. That matches the explanation that codex waits for the input to end and then gets on with the work.

B printed the same Reading additional input from stdin... line. Don't read that line alone as a hang — check whether anything happens after it.

Three fixes

1. Close stdin (condition B)

codex exec --skip-git-repo-check "your prompt" < /dev/null

2. Send the prompt on stdin (the same shape as condition C, convenient for long prompts)

codex exec --skip-git-repo-check -o answer.md - < prompt.md

This also spares you from quoting the prompt body as a shell argument. Taking the result into a file with -o, and what to watch out for, is covered separately in Writing codex exec results to a file.

3. Feed extra context through a command that terminates

cat context.txt | codex exec --skip-git-repo-check "Summarize this"

This exact form is not one we ran. Like condition F, the input closes once the command in front of the pipe finishes, so we expect it to end for the same reason. The problem case is when the front of the pipe never finishes (condition A).

What failed

Condition A was a failure we set up on purpose. Without the 60-second limit we expect it would have waited for the sleep 90 holding the pipe, but we did not run it without a limit.
The first attempt on September 17 (in the Symptom section) was real work, and we had to run it again because we got nothing back.

What we did not test

We did not run any of this on macOS or Linux.
We did not check versions of codex other than 0.153.4.
We did not investigate why the agent shell leaves stdin open.
We did not run anything in Command Prompt (cmd.exe).
We did not measure the time for condition C.