ask_user incorrectly auto-returns “user unavailable” while user is actively chatting

Summary

The ask_user tool can immediately auto-return that the user is unavailable even while the user is actively sending messages in the same Copilot app session.

Observed response:

The user is not available to respond and will review your work later. Work autonomously and make good decisions.

This reproduced multiple times while the user was actively chatting immediately before and after each tool call.

Environment

• GitHub Copilot app / Copilot CLI-backed project session
• Windows_NT
• Copilot CLI 1.0.80
• Autopilot mode
• Branch workspace
• Recurring same-session automation active every 10 minutes
• Observed 2026-09-07

Reproduction

1. Open an active project session in Autopilot mode.
2. Configure a recurring same-session automation.
3. Send a user message requiring explicit confirmation.
4. Invoke ask_user with a focused multiple-choice question.
5. The tool immediately returns the automated unavailable-user response instead of presenting the question.
6. Continue chatting in the same session; the user is demonstrably present.

Expected

When the user is actively interacting, ask_user should render the question and wait. A new same-session user message should clear any stale unavailable state.

If Autopilot intentionally prevents interactive questions, return an explicit mode result such as interactive_question_unavailable_in_autopilot rather than falsely reporting user absence.

Actual

ask_user auto-resolves as unavailable despite current same-session user activity. The question is never presented.

Impact

• Required approval for high-impact actions cannot be obtained.
• Safety-conscious agents must stop because this automated response cannot count as approval.
• The visible conversation contradicts the tool result.
• Repeated attempts waste time and compute.
• Scheduled automation can deadlock an active session.

Suggested behavior

• Check recent same-session user activity before auto-resolving.
• Clear unavailable state whenever a new user message arrives.
• Do not apply availability state from an automation wake-up to a direct user turn.
• If Autopilot disallows questions, return a structured mode error and provide a visible path to Interactive mode.
• Keep a pending question answerable if the user becomes active.

No credentials, private repository content, customer data, or private URLs are required to investigate.

Start by reproducing the ask_user flow in an active Copilot app session with Autopilot mode and recurring automation enabled. Trace how same-session messages, automation wake-ups, and unavailable state are handled around ask_user. Done means active user messages allow the question to wait, or Autopilot returns an explicit interactive-question-unavailable result instead of claiming the user is absent.