Esc in /tasks overlay also dismisses active question prompt
- 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
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