Codex can now keep coding while it waits for your answer

Long-running coding agents face an awkward choice when they need a developer’s input. They can stop and wait or make an assumption and keep working. Now, OpenAI is testing a third option for Codex that allows the agent to ask the question, continue with any work that doesn’t depend on the answer, then adjust when the developer responds.

On Tuesday, OpenAI merged send_user_message_async into the public Codex repository. Once Codex sends the message, the tool immediately returns an accepted response to the model. Codex can then call another tool, inspect another file, or continue generating its answer rather than sit idle.

The feature has not been announced as a general Codex capability, and the public code does not identify which model or Codex interface will receive it first, but it proves OpenAI is working on a different relationship between coding agents and the developers supervising them.

OpenAI did not respond to questions from The New Stack before publication.

Async messaging replaces blocking

Codex already has a request_user_input tool for asking developers short questions; it works by waiting for a response before returning control to the model.

With the asynchronous tool, Codex doesn’t wait, it sends the question or update to the developer, receives confirmation that the message was accepted, and continues the current turn. Any reply comes back later as a new user message.

An integration test included with the change demonstrates the difference. The test has Codex send the update “Still investigating.” The tool returns an accepted result, and the model receives another opportunity to respond within the same turn before producing its final message.

Codex can report what it is doing or ask for a decision while continuing work that does not depend on the response.

OpenAI also avoids inserting a second, synthetic copy of the developer-facing update into the model’s input. The original tool call and its accepted result remain part of the exchange, but the message is not added again as a normal assistant response. As a side channel of sorts, Codex can report what it is doing or ask for a decision while continuing work that does not depend on the response.

Subagents do not receive the tool per the registration logic in the merged code. A Codex task using several subagents would still have one agent responsible for communicating with the developer.

Flag removed within hours

The tool initially required two conditions. A developer had to enable an experimental send_async_message feature flag, and the selected model had to advertise support for the tool. OpenAI removed the first requirement less than a day later. A second merged pull request marks the local flag as removed and makes model support the only remaining switch.

Codex will now register the tool for a root agent whenever the selected model lists send_user_message_async as one of its supported experimental tools. Existing configuration containing the old flag will still be accepted, but the setting no longer controls whether the tool appears.

That change suggests OpenAI intends to control availability via model metadata rather than by asking developers to enable an experimental Codex setting. The public repository does not name a supported model, provide a release date, or say whether the tool will appear first in ChatGPT Work, the Codex desktop app, the CLI, or an IDE extension.

No checkpoint, no rollback

Keeping Codex moving saves time, but it creates a timing problem. Say Codex asks whether a project should use PostgreSQL or SQLite. It can inspect the repository or run tests while it waits, but nothing forces it to stop before that decision affects the code. Codex could begin implementing SQLite just before the developer replies with PostgreSQL.

There is no checkpoint preventing the agent from moving past the decision, and Codex won’t automatically undo work that conflicts with whatever the developer eventually says.

The pull request doesn’t introduce a way to resolve that conflict if Codex keeps working while it waits for an answer: the question never expires, there is no checkpoint preventing the agent from moving past the decision, and Codex won’t automatically undo work that conflicts with whatever the developer eventually says.

The reply isn’t explicitly attached to the question that prompted it, either. Although the outgoing message includes an internal tool call ID, the developer’s answer is returned as ordinary user input rather than a structured response linked to that particular question.

Steer or restart, not reconcile

Codex core exposes a start-or-steer path. If the thread is busy, the input can steer the active turn. If Codex is idle by the time the message arrives, the same input can begin a new turn.

Those checks address where the message should go, but they don’t determine whether the instruction has become stale.

If the developer responds while the original turn is still running, Codex can use the answer in its next model call. If the turn has already ended, the answer becomes a follow-up request. In either case, Codex has to compare the new instruction with the work it has already completed and decide what needs to change, which could mean undoing code it wrote only moments earlier because it continued in a direction the developer never intended.

It leaves Codex to manage the consequences when work continues past the decision it was waiting for.

The post Codex can now keep coding while it waits for your answer appeared first on The New Stack.