{
  "id": 18588143,
  "title": "Works in the Terminal, Hangs When Called by an Agent: The codex exec stdin Trap",
  "url": "https://urgent.news/2026/11/06/works-in-the-terminal-hangs-when-called-by-an-agent-the-codex-exec",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-06T23:12:30.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/noptium/works-in-the-terminal-hangs-when-called-by-an-agent-the-codex-exec-stdin-trap-985"
  },
  "original_language": "en",
  "account": "I attempted to use codex exec from an AI agent's tool runner, but the process never responded. The delay lasted over ten minutes, even though the command itself was correct. When the command is entered manually, stdin is connected to the terminal, so there is no wait. The difference lies in how the caller connects stdin. This guide is for anyone running codex exec from scripts, CI, other programs, or AI agents. If you only use it from a terminal, you can skip it.\n\nThe cause of the issue lies in the way stdin is handled. In my environment (Codex CLI 0.164.0), the agent's execution environment was passing codex exec a pipe as stdin. The official documentation specifies that when stdin is piped and a prompt argument is provided, the argument is treated as the instruction, and the piped input is considered additional context. To ensure the entire stdin is the prompt, omit the argument or use codex exec -.\n\nThe hang occurs when EOF never arrives, and Codex thinks additional context is still coming. This results in the process waiting indefinitely. There is no mention of this hang or workaround in the official documentation.\n\nTo resolve the issue, the stdin must return EOF immediately. In my environment, I redirected stdin from /dev/null, and a high-effort consultation task finished in about 13 seconds. Now, I append /dev/null to every call from this environment. Codex will then decide there is no additional context and move on. Piping input is not inherently problematic; the issue arises when stdin remains open when no input is intended.\n\nThe solution varies depending on the caller:\n\n1. For direct terminal input, no additional changes are needed.\n2. For scripts, check how stdin is connected. If no input is planned, add /dev/null. If input is planned, explicitly use a pipe.\n3. When launching codex exec as a child process, check the stdin setting of the API used. If no input is planned, point stdin at /dev/null or close it immediately after launch. If input is passed, ensure it is closed after writing.\n4. For AI agents' tool runners, always append /dev/null to any codex exec call that does not pass input on stdin. Include this in runbooks or instructions to prevent forgetting.\n5. If input is intentionally supplied on stdin, distinguish between providing an instruction + additional context and using the entire stdin as the prompt. Omit the argument or use codex exec - to make the whole of stdin the prompt.",
  "summary": "I called codex exec from an AI agent's tool runner, and no response ever came back. The hang I observed lasted more than 10 minutes. The prompt was passed as an argument, and there was nothing wrong with the command itself. When you type the command by hand, stdin is connected to your terminal, so the wait never happens. The difference is how the caller connects stdin. This post is for anyone who…",
  "key_points": [
    "Codex exec hangs when called by agent, not terminal",
    "Agent passes stdin as pipe, causing indefinite wait",
    "Append /dev/null to resolve issue for scripts and tools"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}