Ctrl+T thinking toggle provides no screen reader feedback for state changes
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- shell
- Domain
- accessibility, cli
Research direction
Start at the Ctrl+T keyboard shortcut handler and trace how the screenReader setting and terminal status output are handled. Confirm the toggle's enabled and disabled states, then verify that each press produces an audible or textual state message for screen readers; the status bar or terminal output should make the change clear.
Written by the indexing model from the issue text.
Description
Describe the feature or problem you'd like to solve
When pressing Ctrl+T to toggle the reasoning/thinking display on or off, there is no textual or audible feedback indicating the current state of the toggle. Screen reader users have no way to know whether thinking mode is enabled or disabled after pressing the shortcut.
The status bar does not change to reflect the thinking state -- it shows the same content (/ commands . ? help and the model name) regardless of whether thinking is on or off. The only way to discover the current state is to submit a prompt and observe whether reasoning text appears in the response.
This was tested on Windows with NVDA and Copilot CLI v1.0.36, with the screenReader setting enabled in settings.json. Pressing Ctrl+T produces no speech output and no visible text change that the screen reader can detect.
Proposed solution
When Ctrl+T is pressed, output a brief status message to the terminal indicating the new state, for example:
- "Thinking: enabled"
- "Thinking: disabled"
This would allow screen readers to announce the change and give all users confirmation that the toggle took effect. The beep setting could also optionally produce distinct tones for each state.
- Dominant language
- Shell
- Stars
- 11.2k
- Forks
- 1.9k
- Avg merge
- 14h 16m
- Merged PRs (30d)
- 6
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/copilot-cli
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
github/copilot-cli#4932 ·
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
github/copilot-cli#4909 ·
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
github/copilot-cli#4906 ·
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/copilot-cli#4848 ·
-
area:agents area:mcp
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/copilot-cli#4729 ·
All issues in github/copilot-cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug easy help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
lacs-project/sysknife#503 ·
-
help wanted kind/documentation
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
liquidmetal-dev/flintlock#1239 ·