GeezerVison

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6b48421c38

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f7d3973a2f

Documentation check review of PR #31310 (head 1dc6bce).

Documentation check review of PR #31310 (head 9e7a248).

Approving. The chatd side and the overall direction look good to me.

⚠️ Must resolve before this stack merges: steer is now the default on main

This stack is based on e746555 (6 Nov). I merged the steer stack (CODAGT-1140) on 9 Nov, after this stack was cut, and it made steer the default busy_behavior for chat messages. So this one's on me.

What that changes for this stack:

• The question card sends its answer through submitChatTurn with no busy_behavior (handleSendAskUserQuestionResponse in AgentChatPage.tsx), and on main an empty busy_behavior now means steer. After a rebase, an answer sent while the agent works reaches the model before its next model call in the same turn. It no longer waits for the turn to end.
• The PR body says "while a turn runs, the answer is queued and starts the next turn", and lists steering an answer into a running turn (CODAGT-1140) as a follow-up outside this stack. Neither is true on main any more.
• The UAT covered the queue behaviour, not this one. The tool description and status text still read fine with steer, but nobody has exercised this flow yet.
• This PR's Go code merges cleanly with main (only docs/coder-agents/index.md conflicts). The frontend PRs conflict with the steer queue code in chatQueueReconciliation.ts and chatStore.ts, and #31294 changes the "Send now" path, which the steer stack redesigned.

Could we rebase the whole stack onto current main, update the PR body, and re-run the "answer while the agent works" UAT with steer before any of it merges? Steer should make this feature better, since an answer can now change the running turn instead of arriving after it.

Generated by an agent on behalf of the user

A thought on the ask_user_question descriptions in chattool/askuserquestion.go. It is a direction to consider, not a required change.

The async description is 815 characters, and about half of it repeats text that the model already sees elsewhere:

• The result's status already tells the model not to wait and to continue with other work, and it gives the answer prefix with the call ID.
• The schema already requires header, question and 2 to 4 options, and the handler rejects any other count.
• The label description already says how to write an option.

Could the descriptions carry only what the model needs before it calls the tool, and leave the rest to the schema and the result? That is: what the tool does, when to use it, that the answer arrives later, and that a new question replaces an unanswered one. Guidance that matters only after the call, such as "if you cannot continue, end your turn", could live in the status text. The model reads it at the moment it decides whether to stop, and it costs tokens only in chats that call the tool. The last two sentences of the plan mode description repeat the schema in the same way.

For scale, Codex's async equivalent (request_user_input_async) is about 560 characters, and its blocking request_user_input is about 120. A rough cut along these lines puts the async description near 320 characters.

If the option guidance is repeated because models ignored the label description without it, that is a good reason to keep it. Nobody has run an eval on either wording, so this is about less repetition, not a proven improvement.

Generated by an agent on behalf of the user