Describe the feature or problem you'd like to solve
When using the Copilot CLI for longer-running or multi-step tasks, the process often pauses waiting for user input (e.g., confirmation prompts or follow-up instructions). There is currently no built-in mechanism to notify the user that input is required. This creates a poor UX where: The CLI appears to still be working or “thinking” The user may switch context (editor, browser, etc.) Copilot is actually blocked waiting for input, causing unnecessary delays This is especially noticeable when running Copilot in background panes (e.g., tmux) or alongside tools like Emacs/vterm.
Proposed solution
Add a mechanism to notify the user when Copilot CLI is waiting for input.
Possible approaches:
Emit a terminal bell (\a) when prompting for input
Add a flag such as:
copilot --notify-on-input
Support a configurable notification hook:
COPILOT_NOTIFY_HOOK="notify-send 'Copilot needs input'"
Optionally integrate with OS-level notifications (Linux/macOS)
Prevents wasted time waiting unknowingly
Improves usability for long-running or semi-autonomous workflows
Makes Copilot CLI more viable for background or multi-pane usage
Aligns with how developers actually multitask in terminal-heavy environments
Example prompts or workflows
Example prompts or workflows
Running a refactor across multiple files:
copilot "refactor this module to use async patterns"
Copilot pauses for confirmation, but the user has already switched context.
Generating and reviewing code changes:
copilot "apply these changes and show diff before committing"
CLI waits for approval without any notification.
Iterative instruction workflow:
copilot
analyze this file
suggest improvements
Copilot asks follow-up questions, but the user doesn’t notice immediately.
Running Copilot in a tmux split while editing elsewhere:
Copilot blocks on input
No visible signal unless actively watching that pane
Additional context
No response
Describe the feature or problem you'd like to solve
When using the Copilot CLI for longer-running or multi-step tasks, the process often pauses waiting for user input (e.g., confirmation prompts or follow-up instructions). There is currently no built-in mechanism to notify the user that input is required. This creates a poor UX where: The CLI appears to still be working or “thinking” The user may switch context (editor, browser, etc.) Copilot is actually blocked waiting for input, causing unnecessary delays This is especially noticeable when running Copilot in background panes (e.g., tmux) or alongside tools like Emacs/vterm.
Proposed solution
Add a mechanism to notify the user when Copilot CLI is waiting for input.
Possible approaches:
Emit a terminal bell (\a) when prompting for input
Add a flag such as:
copilot --notify-on-input
Support a configurable notification hook:
COPILOT_NOTIFY_HOOK="notify-send 'Copilot needs input'"
Optionally integrate with OS-level notifications (Linux/macOS)
Prevents wasted time waiting unknowingly
Improves usability for long-running or semi-autonomous workflows
Makes Copilot CLI more viable for background or multi-pane usage
Aligns with how developers actually multitask in terminal-heavy environments
Example prompts or workflows
Example prompts or workflows
Running a refactor across multiple files:
copilot "refactor this module to use async patterns"
Copilot pauses for confirmation, but the user has already switched context.
Generating and reviewing code changes:
copilot "apply these changes and show diff before committing"
CLI waits for approval without any notification.
Iterative instruction workflow:
copilot
Copilot asks follow-up questions, but the user doesn’t notice immediately.
Running Copilot in a tmux split while editing elsewhere:
Copilot blocks on input
No visible signal unless actively watching that pane
Additional context
No response