Cursor-agent -p: AskQuestion is auto-skipped in headless mode, and only some models get the tool

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

In cursor-agent -p the AskQuestion tool is answered without a user. With Composer 2.5 the model calls it and the harness replies at once:

{"type":"interaction_query","query_type":"askQuestionInteractionQuery",
 "response":{"askQuestionInteractionResponse":{"result":{"rejected":
 {"reason":"Questions skipped by the user, continue with the information you already have"}}}}}

The model reads that as “the user skipped it” and moves on. Nobody was asked and there is no way to supply an answer in print mode, so a script can’t tell a skipped question from one that was never shown. Related but different: `AskQuestion` tool can return synthetic skip string with highly variable, unpredictable delay is the same string arriving in the IDE after a delay.

Separately, the tool is model-gated. The same command on Grok 4.5 High, and on --model auto, gets no AskQuestion tool at all (model says it has no such tool), in default and plan mode. --model auto doesn’t say which model it routed to, so that row can’t be pinned down.

Steps to Reproduce

  1. Run: cursor-agent -p --trust --output-format stream-json --model composer-2.5 'Ask me one multiple-choice question using your built-in tool for asking the user a question (not plain text): "Pick a color" with options Red and Blue. If you have no such tool, reply NO_ASK_TOOL.'
  2. Read the tool_call (askQuestionToolCall) and the interaction_query response above.
  3. Repeat with --model cursor-grok-4.5-high and --model auto: no askQuestionToolCall.

Expected Behavior

Print mode should either surface the question (a documented way to answer, for example an event the caller can reply to) or return an error result that says no user is attached, different from a user’s skip, so the model and the caller can tell. It would help if the docs said which models get AskQuestion.

Operating System

MacOS

Version Information

cursor-agent 2026.09.28-64d2043, macOS (Apple silicon). Re-run on that build on 2026-10-01: Composer 2.5 called askQuestionToolCall and got the “Questions skipped by the user” rejection; cursor-grok-4.5-high made no tool call and replied NO_ASK_TOOL. (First runs were 2026-09-25, build not recorded.) --model auto was not re-run (09-25 result only). Table with the runs: askmux/MATRIX.md at main · iShaldam/askmux · GitHub

For AI issues: which model did you use?

Composer 2.5 (tool called, auto-skipped); Grok 4.5 High and Auto (no tool)

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report and the run table, it really helps.

On the first part, you’re right. In print mode there’s no one to answer, so the CLI automatically rejects AskQuestion, and it uses the same wording Questions skipped by the user as a real skip. So right now you can’t tell a synthetic reject from a real skip. I’ve passed this to the team so print mode reports it as a separate case, like “no user attached”, instead of a user-skip. I’ll reply here when there’s an update.

The second part, model gating, works as intended. Some models, including the Cursor Grok 4.5 family, are configured to ask questions as plain text instead of using the AskQuestion tool, and Auto can route to a model like that. So tool availability depends on which model is actually serving the request. I’ll pass along your feedback about documenting which models get AskQuestion.

Until this changes, here are two tips for scripts:

  • In -p, any reject of askQuestionInteractionQuery is automatic, the question is never shown. You can treat that event as “not shown”.
  • If you actually need to answer, ask the agent in the prompt to write questions as plain text and stop. Then reply with cursor-agent -p --resume <session_id> "your answer", using the session_id from the stream-json output.

The ACP method cursor/ask_question in the docs is meant to be the answerable path. Right now ACP sessions also don’t get this tool, we’re already tracking it, and your report helped confirm it. Let me know if the workaround doesn’t cover your use case.