codex exec hangs in skill bash blocks: missing </dev/null causes 'Reading additional input from stdin' deadlock (codex CLI 0.120.0+)

[loning]

Summary

Every codex exec invocation in gstack skill files hangs forever on codex CLI 0.120.0+ (current released version). Symptom: process at 0% CPU, stdout empty, stderr shows Reading additional input from stdin.... The skill workflow then times out or sits indefinitely.

Reproduced today against gstack v0.16.3.0 while running /plan-eng-review with codex CLI 0.120.0. First call (with --enable web_search_cached) sat at 0% CPU for 13+ minutes, no output. Second call (without web_search) hit timeout 124 with Reading additional input from stdin... in stderr. Third call adding </dev/null succeeded in 2:25.

Root cause

codex exec --help (0.120.0):

[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.

When skill bash blocks invoke codex exec "\$PROMPT" ..., the parent shell's stdin is inherited. In Claude Code's Bash tool (and any background or non-TTY context), stdin is not a TTY but also not closed — codex detects this as "stdin is piped, append it" and blocks waiting for EOF that never comes. The positional \$PROMPT arg is silently followed by an indefinite wait for stdin.

Independent contributing issue: --enable web_search_cached is deprecated in 0.120.0 and seems to make hangs more likely / more silent (no clear error).

Fix

Add < /dev/null to every codex exec invocation. The prompt is already passed as an arg, so no real stdin input is needed.

Diff (one-liner per call site):

```diff

• codex exec "" -C "$_REPO_ROOT" -s read-only -c 'model_reasoning_effort="high"' --enable web_search_cached 2>"$TMPERR_PV"

• codex exec "" -C "$_REPO_ROOT" -s read-only -c 'model_reasoning_effort="high"' < /dev/null 2>"$TMPERR_PV"
  ```

Recommend dropping --enable web_search_cached at the same time (deprecated and the prompt template doesn't need it for outside-voice review).

Affected files in v0.16.3.0

• `plan-eng-review/SKILL.md:1057` — outside voice plan review
• `plan-ceo-review/SKILL.md:1388` — outside voice plan review
• `codex/SKILL.md:840, 952, 986` and `codex/SKILL.md.tmpl:204, 316, 350` — codex review modes
• `review/SKILL.md:1330` — adversarial review

(All four skills share the same broken pattern.)

Repro

```bash
codex --version

codex-cli 0.120.0

Hangs forever (no </dev/null):

codex exec "say hi" -s read-only > out 2> err &
sleep 10
cat err

Reading additional input from stdin...

ps -o pcpu -p $!

0.0

Works:

codex exec "say hi" -s read-only < /dev/null > out 2> err
echo $?

0

```

Why it wasn't caught earlier

When gstack skills are invoked from an interactive Claude Code session attached to a real terminal, stdin is a TTY and codex 0.120.0 takes the fast path. The bug only surfaces when:

• Bash tool is in non-TTY mode (most common — happens silently)
• Skill is invoked via background runner / OpenClaw / orchestrator
• Skill is run via cron / CI

For users hitting the TTY path it looks like nothing is wrong. For everyone else it looks like codex / gstack / their network is broken.

Workaround for users on v0.16.3.0

In CLAUDE.md, add a project-level rule that says any codex exec invocation must include `</dev/null`, and patch invocations inline when copying from skill files. (I've added this to my own CLAUDE.md after debugging it today.)