Bug: hangs at 'Reading additional input from stdin...' in non-TTY environments (TERM=dumb)

Bug Description

codex exec hangs indefinitely at Reading additional input from stdin... when run in a non-TTY environment (e.g., from a script, CI, or an agent framework like Hermes Agent). The command never reaches the actual model invocation.

In contrast, running the exact same command interactively in a terminal works perfectly.

Environment

• OS: macOS 25.2.0 (arm64)
• Codex CLI: v0.133.0
• Shell: /bin/zsh
• TERM: dumb (set by the parent process, Hermes Agent)
• Auth: ChatGPT OAuth (authenticated, last_refresh: 2026-06-08T14:38:26Z)
• Model: gpt-5.4
• Network: Proxy via HTTP_PROXY/HTTPS_PROXY (verified working)

Steps to Reproduce

1. Install Codex CLI v0.133.0 on macOS
2. Authenticate with codex login
3. Set TERM=dumb to simulate a non-TTY environment
4. Run:

``bash
TERM=dumb codex exec "hello"
``

1. Observe: command hangs at Reading additional input from stdin... indefinitely

Expected Behavior

codex exec should process the prompt and return a response, regardless of whether stdin is a TTY. The exec subcommand is documented as "Run Codex non-interactively" — it should not require an interactive terminal.

Actual Behavior

$ TERM=dumb codex exec "hello"
Reading additional input from stdin...
<hangs forever>

No output, no error, no timeout. The process must be killed manually.

Additional Context

What works

• Running codex exec "hello" in an interactive terminal (TERM=xterm) works fine
• The same proxy/network configuration works when run interactively
• Auth is valid (confirmed via interactive session)

What doesn't work

• TERM=dumb codex exec "hello" — hangs
• codex exec "hello" < /dev/null — hangs
• echo "" | codex exec "hello" — hangs
• Using expect to simulate a TTY — hangs
• Using script -q /dev/null codex exec "hello" — hangs

Root cause hypothesis

Codex CLI appears to check if stdin is a TTY and, when it's not, enters a blocking read on stdin waiting for additional input. The message Reading additional input from stdin... suggests it's waiting for the user to type something and send EOF, but in automated environments there's no way to signal completion.

The exec subcommand should ideally:

1. Use the provided prompt argument directly
2. Not wait for stdin input when a prompt is already provided via CLI argument
3. Support a --no-stdin flag or similar to skip stdin reading entirely

Impact

This blocks using Codex CLI in:

• Agent frameworks (Hermes Agent, AutoGPT, etc.)
• CI/CD pipelines
• Scripted automation
• Any non-interactive environment

Logs

When run interactively (works):

OpenAI Codex v0.134.0
--------
workdir: /Users/craipy/ai-stock-picker
model: gpt-5.4
provider: openai
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR] (network access enabled)
reasoning effort: medium
session id: 019ea7bb-5d84-7870-8f16-3e5037428b42

When run non-interactively (hangs):

Reading additional input from stdin...
<hangs forever, no further output>

Proposed Fix

Add a --no-stdin flag or detect when a prompt is already provided via argument and skip stdin reading entirely:

// In exec command handler
if prompt.is_some() && !stdin_is_tty() {
    // Don't wait for stdin — prompt already provided
    return run_with_prompt(prompt.unwrap());
}

Or simply respect the documented behavior: exec is "non-interactive" and should not block on stdin.