A CLI that took a full prompt as an argument and still hung waiting for stdin to close

I called a review tool from a script, passing the entire prompt as a single command-line argument. No explicit shell pipeline was feeding it anything else. It printed one line — Reading additional input from stdin... — and then nothing.

$ codex exec --skip-git-repo-check "<full prompt text>"
Reading additional input from stdin...

No more output. Past the shell tool's own timeout, the process got moved to the background automatically, with a message to that effect. Polling its status afterward returned the same thing every time: still running. It had not finished by the time I stopped checking.

What I checked first

The prompt itself wasn't the problem — I'd already passed the whole thing as the argument, and nothing in it was malformed. The tool wasn't crashing; it was waiting for something. The one concrete clue was the line it printed: it was explicitly announcing that it intended to read more input from stdin, even though the argument already contained a complete prompt.

Root cause

The tool appears to support two separate input channels — a prompt given as an argument, and additional input read from stdin — and the two aren't mutually exclusive. Having a complete prompt in the argument doesn't stop it from also trying to read stdin. In the shell environment I was calling it from, stdin did not send an end-of-file signal on its own. So the tool sat there waiting for an EOF that, in this environment, doesn't arrive by itself.

That distinction matters because of what it isn't: it isn't the tool being slow, and it isn't the tool being unresponsive. What I observed was consistent with a process waiting on an input stream that, in this environment, doesn't close on its own.

The fix

Close stdin explicitly, so the tool gets its EOF immediately instead of waiting on a channel nothing else is going to signal:

codex exec --skip-git-repo-check "$(cat <<'EOF'
...prompt content...
EOF
)" < /dev/null

One detail from getting there: writing the prompt to a separate file and reading it back with cat /path/to/file, combined with the same < /dev/null redirect, got rejected by this sandbox's static analyzer — "Contains shell syntax that cannot be statically analyzed." The heredoc form above, with the prompt written inline in the command itself, was not rejected and ran. In this environment, that is what got the redirect past the sandbox's analysis step — I have not tried every other way of writing it.

What I verified

With < /dev/null added, the same call printed its verdict and exited in the foreground, somewhere between a few seconds and roughly a minute and a half, with no more Reading additional input from stdin... and no move to the background. I ran this twice, with two different prompts. Both finished in the foreground both times.

That confirms the fix resolves this exact hang, for this exact calling shape, in this environment, twice. It does not tell me why the tool reads stdin at all when the argument already contains a full prompt — I didn't read its source, and I'm not claiming to know its internals. It also doesn't tell me whether some other shell environment closes stdin automatically and would never have hit this in the first place.

What I check now

If a call to a CLI that accepts a full prompt as an argument stalls with no more output, I no longer read that as the other side being slow or unresponsive. I check whether stdin was ever closed. For this specific tool, in this specific environment, that means appending < /dev/null by default, not adding it only after a hang shows up.

This article was written with the help of AI. The incident, the commands and the outputs are real and from my own machine; the draft was AI-written, then checked against the original logs and corrected.