github / github/copilot-cli

Esc in /tasks overlay also dismisses active question prompt

Open
#3,430 1 comment 1 reaction 0 assignees View on GitHub
area:agents area:input-keyboard
Dominant language
Shell
Stars
11.2k
Forks
1.9k
Avg merge
14h 16m
Merged PRs (30d)
6

Description

### Describe the bug

When the Copilot CLI `/tasks` overlay is open and the agent asks a question, pressing `Esc` to close the task/subagent menu also affects the underlying question prompt.

The same `Esc` keypress appears to be handled twice:

1. It closes the `/tasks` overlay.
2. It also dismisses or skips the active question prompt underneath.

This prevents the user from answering the question and can cause the agent to continue with an unintended skipped/default response.

This seems inconsistent with the documented `Esc` behavior for Copilot CLI, where an open dialog, overlay, or picker should be closed before `Esc` acts as a broader cancel action.

References:

- [`/tasks` command reference](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference)
- [`Esc` behavior in Copilot CLI](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/cancel-and-roll-back)
- [`/fleet` and subagent task execution](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/fleet)

### Affected version

GitHub Copilot CLI 1.0.49.

### Steps to reproduce the behavior

1. Start an interactive Copilot CLI session.
2. Start a task that uses subagents or background tasks.
3. Open the task/subagent manager with `/tasks`.
4. While the `/tasks` overlay is open, wait for the agent to ask a question or clarification.
5. Press `Esc` once, intending only to close the `/tasks` overlay.
6. Observe that the active question is also skipped or dismissed.

### Expected behavior

Pressing `Esc` while the `/tasks` overlay is open should only close that overlay and return focus to the active question prompt.

The question should remain visible and answerable.

### Additional context

This looks like a key handling or focus propagation issue. The `/tasks` overlay appears not to consume the `Esc` event after using it to close itself, so the same keypress reaches the global cancel handler or the underlying question UI.

A possible fix would be to make the `/tasks` overlay treat `Esc` as handled when it closes the overlay, preventing the key event from being forwarded to lower-priority UI layers.

A regression test could cover this stacked UI case:

1. An active question prompt is visible underneath the `/tasks` overlay.
2. The user presses `Esc` once.
3. Only the `/tasks` overlay closes.
4. The question prompt remains open and answerable.

Contributor guide

Open the contributing guide

Research direction

Reproduce the stacked UI case by opening the /tasks overlay while a question prompt is active, then pressing Esc once. Trace Esc handling from the /tasks overlay to the underlying question prompt and add a regression test covering that sequence. Done means the overlay closes while the question remains visible and answerable.

Written by the indexing model from the issue text.

Assessment

Tech stack
shell
Domain
cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.