Codex waiting for input: what it wants

Codex waiting for input can mean an approval prompt, a clarifying question, or a shell command that hasn’t finished. Check the last message or tool event before changing permissions.

For an approval, review the requested action and your approval policy. For a question, reply in the session or resume it with your answer. For an unfinished command, inspect its output and replace interactive or long-running commands where appropriate. Disabling approval prompts leaves the other two cases unresolved.

Why is Codex waiting for input?

The last visible action tells you where to investigate. A quiet terminal alone doesn’t identify the cause.

For scripted work, Codex already has a non-interactive entry point. Use its event stream when you need more evidence about where execution stopped:

codex exec --json "Inspect the project and report which checks I should run."

--json prints events to stdout as JSONL. Without it, non-interactive mode normally sends progress to stderr and the final agent message to stdout, so check both streams before concluding that nothing happened. See the Codex non-interactive mode documentation.

An unfinished command deserves inspection before a restart. If the last command launched a dev server, check whether it is serving the app; the task may need a separate server process and a readiness check. If a program is asking for input, use that program’s documented non-interactive option or supply its configuration in advance. Avoid piping a blanket yes into an unknown prompt.

Git has a specific option for avoiding its output pager:

git --no-pager diff

--no-pager keeps Git output out of a pager. It addresses that particular wait, without changing Codex permissions. In Claude Code, you can also background a Bash command with Ctrl+B, or ask Claude to run it in the background; under tmux, press twice. Claude can read the background output file while you continue the conversation.

Is it an approval prompt or a question?

An approval asks whether an action may execute. A clarifying question asks what the implementation should do. Permission to edit files doesn’t resolve an ambiguous requirement, such as whether a fix may change a public interface.

The distinction also exists in Codex’s integration protocol. App-server command approvals use item/commandExecution/requestApproval, while user-input requests are a separate mechanism. A commandExecution item records command status and output, with an optional exit code and duration. If you’re diagnosing a client integration, inspect those events separately. The app-server approval documentation describes the client response required for an approval request.

For a task question, answer with the decision and its scope. For example, tell the agent to preserve the public interface and add a regression test, rather than replying only with permission to continue.

Codex can resume a saved conversation natively:

codex resume

That opens a picker for previous interactive sessions. To include non-interactive sessions in the picker, use:

codex resume --include-non-interactive

For a scripted continuation, replace SESSION_ID with the recorded session id:

codex exec resume SESSION_ID "Preserve the public interface. Add a regression test for the existing behavior."

These commands continue existing context. You can supply the missing decision without starting the task over with a fresh prompt.

How do you stop Codex asking for approval in non-interactive runs?

Use codex exec for unattended work and check the flags in your installed version. The commands here were checked against Codex CLI 0.166.0. Its exec help has no separate --ask-for-approval option, and its headless implementation normally defaults to never. An apparent codex exec approval prompt is a reason to inspect the actual command and events before adding flags.

Workspace edits need a suitable sandbox. Non-interactive mode defaults to read-only; this invocation permits workspace edits:

codex exec --sandbox workspace-write "Fix the failing test, run the relevant checks, and leave changes uncommitted."

Approval policy and sandbox access are separate settings. The sandbox controls filesystem and command-network access. Approval policy controls when an action requires approval. In an interactive session, you can explicitly disable approval requests while retaining the workspace sandbox:

codex --ask-for-approval never --sandbox workspace-write

With never, execution failures return to the model without asking you for approval. It doesn’t grant unrestricted access or answer task questions. The sandbox and approval guide explains the separation.

The installed CLI also offers --approve-for-me for automatic approval review with the workspace-write sandbox. The broader --dangerously-bypass-approvals-and-sandbox option removes command sandboxing as well as confirmation prompts; it is intended for externally sandboxed environments. Neither option supplies a missing product decision.

What happens to a question nobody answers?

For a direct Codex session, you can return with an answer using the resume commands above. If you’re delegating through Claude Code and need questions tracked while you’re elsewhere, foreman is one option. Claude writes a task contract, Codex works in a git worktree, and a local daemon supervises the run through codex app-server. The guide to using Codex from Claude Code compares it with the other ways to delegate.

Each new foreman thread receives an ask_orchestrator tool. When Codex calls it, foreman assigns an id such as q1, holds the tool call open, and reports the run as waiting. Claude can inspect the named run and answer the question:

foreman status fix-tests
foreman answer fix-tests q1 "Preserve the public interface; make the fix inside the implementation."

The recording below shows an actual answer to a scope question. The reply permits one specific line edit and keeps the existing strict test comparison.

$ foreman answer site-commands q1 "Your test is right and the page copy is wrong. Change the npx option in site/src/data/landing.ts to exactly \"npx @steamfield/foreman\" (I made the same one-line change on the base branch, so the hunks will match at merge). You may edit that one line of landing.ts; nothing else in it. Keep the strict comparison."

ok
next: foreman wait --all --after eyJfdGFnIjoiR3JvdXBDdXJzb3IiLCJncm91cCI6In4vc3JjL2ZvcmVtYW4iLCJwb3NpdGlvbnMiOnsiZml4LWNsaSI6eyJpZGVudGl0eSI6IjIwMjYtMTEtMDZUMDM6Mzk6NTMuMTg1WjowMWExYWVmMS0wN2YwLTcwODAtOGM1MS0wOGQ1ZDdhZTMwMDQiLCJzZXEiOjMzNTh9LCJmaXgtZGFlbW9uIjp7ImlkZW50aXR5IjoiMjAyNi0xMS0wNlQwMzozOTozNS45NDNaOjAxYTFhZWYwLWM0OTctNzUxMi1hZjYwLWNlMmZjODk0MjcyZiIsInNlcSI6Mzk0N30sImZpeC1zdXBlcnZpc29yIjp7ImlkZW50aXR5IjoiMjAyNi0xMS0wNlQwMzozOTozOS40OTFaOjAxYTFhZWYwLWQyNmMtNzBiMi1iYWMxLWU1NTBhNzk0MDc5YyIsInNlcSI6MjMxOH0sImZpeC13b3JrdHJlZXMiOnsiaWRlbnRpdHkiOiIyMDI2LTExLTA2VDAzOjM5OjQ2LjQxMFo6MDFhMWFlZjAtZWQ3OS03NDcyLWI4MDUtMTY5YjJiZTUwYzQ3Iiwic2VxIjozMjY2fSwic2l0ZS1jb25zb2xlIjp7ImlkZW50aXR5IjoiMjAyNi0xMS0wNlQwOToyNDoxOS4xMjVaOjAxYTFiMDJjLTVlM2UtNzEwMi1iMzZiLTBkMTI1YTY0NGRkNyIsInNlcSI6MzB9LCJzaXRlLWxpZmVjeWNsZSI6eyJpZGVudGl0eSI6IjIwMjYtMTEtMDZUMDk6MjQ6MjAuMjM5WjowMWExYjAyYy02MjlhLTcwMjEtOWIxMy1lYTAzMTdlNjM1NGIiLCJzZXEiOjI4fSwic2l0ZS1ldmlkZW5jZSI6eyJpZGVudGl0eSI6IjIwMjYtMTEtMDZUMDk6MjQ6MjIuNzY3WjowMWExYjAyYy02Yzc3LTcyMDMtYWU1Yy04NGVkYjk4YzY1ODkiLCJzZXEiOjIyfSwic2l0ZS1jb21tYW5kcyI6eyJpZGVudGl0eSI6IjIwMjYtMTEtMDZUMDk6MjQ6MjUuNTI2WjowMWExYjAyYy03NzNjLTdmYzItOWJiOS02YzgwZTgyMjQ1NmEiLCJzZXEiOjI5fX19

Claude can defer a decision it can’t make yet:

foreman defer fix-tests q1 "Waiting for the interface decision."

An unanswered question is also deferred automatically after fifteen minutes by default. start --question-timeout changes that interval. The deferral prompt includes these instructions:

No answer yet; the decision may need a person and can take a while. Continue with all work that doesn’t depend on it.

For the question itself, take no irreversible step and nothing outside the contract; if a safe, reversible default exists, use it and say so; otherwise leave that part undone.

End your turn normally and list the question, and what you did about it, under Open. The answer will arrive as a message later.

This is guidance to the model, not enforcement of its reasoning or choices. The deferred question stays visible as unanswered until answered or superseded. The fifteen-minute timer applies to held ask_orchestrator calls; it doesn’t diagnose a slow shell command or a Codex approval request.

Answering after the agent has moved on

Codex already supports queueing a message for an existing session. Replace SESSION_ID with its UUID or exact session name:

codex queue --thread SESSION_ID --message "Keep the public interface unchanged." --resume

--resume attempts to resume the thread after queueing. If that attempt fails, the command still succeeds with a warning, so check the warning before assuming the agent continued.

In foreman, use answer with the original question id even after deferral. A late answer steers a running turn, or starts a follow-up after inactivity if steering is refused. Answering an already answered id sends a correction with the original question context. Queued answer delivery lives in daemon memory and isn’t reconstructed after a daemon crash.

The orchestrator still owns review and commits. foreman never commits or merges itself; its delegate instructions tell Codex to leave changes uncommitted and avoid pushing. Before committing, inspect the diff and run the repository’s checks. If you choose this workflow, start with the foreman installation and setup instructions.

Running Codex in the background covers checking on and steering a task that is still working.