Codex can now ask and keep going, which deletes the only checkpoint you were getting for free

OpenAI merged a tool called send_user_message_async into the public Codex repository on Tuesday, letting the coding agent ask a developer a question and continue working rather than blocking on the reply ^[1][2]. For anyone supervising long agent runs, that removes the last checkpoint enforced by mechanics instead of by policy: the agent sitting still until a human answers ^[3][17].

Codex already has request_user_input, which waits for a response before returning control to the model ^[3]. The new tool inverts it. The message goes out, the tool immediately returns an accepted result, and the model keeps going in the same turn, calling another tool, inspecting another file, or finishing its answer ^[2]. Any reply arrives later as a new user message ^[4]. An integration test shipped with the change has Codex send the update "Still investigating.", receive the accepted result, and then get another opportunity to act inside the same turn before producing its final message ^[5].

The plumbing is deliberately quiet. OpenAI does not insert a second, synthetic copy of the developer-facing update into the model's input; the original tool call and its accepted result stay in the exchange, but the message is not added again as a normal assistant response ^[6]. Per the registration logic in the merged code, subagents do not receive the tool, so a task running several subagents still has one agent responsible for talking to the developer ^[7].

Then there is the gate. Initially the tool required two things: an experimental send_async_message feature flag enabled by the developer, and a model advertising support for the tool ^[8]. Less than a day later, a second merged pull request removed the flag requirement, leaving model support as the only switch ^[9], taking the conditions from two to one ^[1]. Codex now registers the tool for a root agent whenever the selected model lists send_user_message_async among its supported experimental tools ^[11]. Existing configuration containing the old flag is still accepted, but it no longer controls whether the tool appears ^[10]. The New Stack reads this as OpenAI intending to control availability through model metadata rather than a developer-side setting ^[12]. In operator terms, the on/off decision moves to the far side of the API.

What the change does not include is the part supervision actually rests on. The pull request adds no way to resolve a conflict between work already done and an answer that lands late: the question never expires, there is no checkpoint preventing the agent from moving past the decision, and Codex will not automatically undo work that conflicts with the eventual reply ^[17]. The New Stack's example is a database choice. Ask whether the project should use PostgreSQL or SQLite, and Codex can inspect the repository or run tests while it waits, but nothing stops it from starting the SQLite implementation just before the developer answers PostgreSQL ^[16]. The reply is not explicitly attached to the question that prompted it either, even though the outgoing message carries an internal tool call ID ^[18]. So the ordering guarantee you thought you had from a blocking question is now something you have to build: gate anything that writes files behind an explicit approval step, and treat the async channel as status reporting rather than as a decision point.

Watch for a follow-up pull request that adds expiry, a real checkpoint, or a link between an answer and the question it answers. Also watch which model first advertises support: the public repository names no supported model, gives no release date, and does not say whether the tool lands first in ChatGPT Work, the Codex desktop app, the CLI, or an IDE extension ^[13]. It has not been announced as a general Codex capability, and OpenAI did not respond to The New Stack's questions before publication ^[14][15].