Use of native terminal's cursor
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
For context, I am running Claude Code under Linux's virtual text console.
I am blind and use BRLTTY to render the content of the screen in braille.
As many screen reading programs, BRLTTY by default uses the terminal's native cursor to decide which portion of the screen to show to the user.
As Claude Code does not use the terminal's native cursor, it is not convenient ot enter prompts as you don't know where your cursor is.
The native cursor remains stuck at the bottom of the screen and, should you want to fix a typo you have no clue where the cursor is.
Ideally, using the terminal's native cursor should be the default but, at the very least there should be a way to configure Claude to do that.
In particular, at the beginning when choosing Claude's configuration, there is no option to make it screen-reader friendly and there would certainly be space for such options, because some features of Claude Code like the use of Unicode characters or the display of ephemeral messages is not so convenient when using a screen reader.
What Should Happen?
See above.
Error Messages/Logs
Steps to Reproduce
Simply run Claude under Linux's virtual console and maybe use BRLTTY.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.80
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
_No response_
37 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Yes, it is correct that the present issue is a duplicate of #910, #2237
and #29065. But those have been closed and locked due to lack of
activity and #2237 and #29065 actually show that the problem reported
by the present issue also occurs on Mac. In addition, I have been
told that the same goes for Windows so the problem is really
OS-independent and is an annoyance for all users of assisitive
technologies, no matter theoperating system or screen reader they are
using.
Cc @npitre @csabyke @tugberkayartextcortex @fcnjd @yplassiard
Hi,
I confirm the issue is platform / screen reader independent: I’ve successfully reproduced it on:
A bunch of thanks for having taken the time to do such a complete testing!
@yplassiard Thank you very much for testing, as a user I also confirm to have that problem and would be very happy to see a fix soon.
I'm a screen reader user, namely NVDA on Windows, Orca and Fenrir on Linux. This problem affects me as well; please fix.
thanks!
I bought claude pro and unfortunately I am also affected by this error under NVDA. I know that many in Germany have already complained about this bug.
It would be nice if the problem with tracking was fixed so that I can continue to use my Claude Pro access.
I'm a Claude Pro subscriber. Claude is the least accessible AI. Please care about disabled users.
I am a low-vision Claude pro subscriber and this problem affects me on MacOS and Linux (Debian). Please fix this!
I wanted to buy claude pro, but as an NVDA user I also unfortunately have this problem with tracking.
Please improve the accessibility of claude for blind and visually impaired users!
I've tried claud today and while I've not tried the coding part, the accessibility needs to be improved. In firefox if you write a prompt, the screen reader reads the reply very wierdly, it's chopped up and repeated and you can't actually stop it with control. While on microsoft edge there's no heading making navigation very very hard. This is not worth buying if you are a screen reader user.
I am also hit by this problem. Being a blind professional developer and working with Claude code most of the day, it is quite anoying to always search for the cursor when editing a prompt. Using vi to edit a prompt can help a little but is a bit over overkill for small prompts and the screenreader keeps reading the status bar. An additional problem is that it is quite hard to follow claude codes output with a screenreader since the lines are somehow floating and the screenreader is pulled to the terminal cursor.
I can only confirm the issue I am a professional software developer who is blind and uses NVDA on Windows. Not only is character-by-character navigation or deletion within the prompt input field impossible with the screen reader — the screen reader simply does not read it aloud — but the entire UI dialogs are also very difficult to use. A non-pronounceable caret character is displayed at the beginning of options, and the actual cursor is not being used. I also have the Pro subscription, but I do not feel taken seriously with my issues here. I therefore request that this be fixed. It could certainly be done behind a configuration flag to avoid visual regressions, etc.
I am also having this problem in both windows, and mac.
FWIW, the "gemini" agent from Google has a very very similar appearance
and feel to the Claude Code agent. It looks like they both started from
the same code base at some point. Yet, the gemini command acquired a
--screen-reader command line argument whose help text reads as "Enable
screen reader mode for accessibility."
As a blind NVDA user, I can only support what has been reported here. Please keep accessibility in mind!
I'm a blind Claude Pro user (Windows NVDA) and this is indeed a problem. I can only agree with the others, please care aobut the accessibility, Claude is sadly behind with it already.
Yup, encountering this as well. A fix would be very much appreciated.
nother Max plan user and can confirm this issue
I'm a fully blind Claude Max subscriber, and experiencing this issue as well on both macOS using the VoiceOver screenreader, as well as on Windows using NVDA.
Please support accessible and inclusive design principles by either redesigning the Claude Code TUI in a way that makes it usable for all, or at least adding a screenreader mode that disables the non-standard cursor handling.
I'm blind and use Claude Code on Claude Pro, I face this as well on Windows (NVDA) and Linux. The spam of numbers when the shown time or token usage changes also is real, maybe related to this?
As a blind Claude Max subscriber, I agree with this issue. I'm encountering the same problem on Windows. I'd like to say that Desktop makes things better. But, it has significant issues as well. Considering how well accessibility and other skills can be incorporated, I'm incredibly surprised and dismayed by the fact that we're dealing with inaccessible interfaces.
Terminal emulators render IME preedit text at the physical cursor position, and screen readers / screen magnifiers track the native cursor to follow user input. Previously the cursor was hidden and left wherever the last render write landed — so CJK composition text appeared at the bottom-left corner, and accessibility tools couldn't follow the input.
I am adding declarative cursor positioning so the native terminal cursor follows the text input caret. This should hopefully resolve it in tomorrow's regular release.
Thank you!
Eager to try this!
Leon (2026/03/24 05:18 -0700):
Maybe we can see how the situation evolves once we have the cursor dealt
with correctly and open a dedicated issue for the problem.
I'd suggest that, if one of us opens an accessibility related issue,
this person mentions all the persons who commented here.
I could even imagine us creating a dedicated mailing list or
communication means to discuss our needs among us so that the issues and
feature request are more collective (I think it won't always be as easy
as "please use the native terminal cursor").
Thank you very much for the quick response. ON Windows, this effects speaking the deleted character when the backspace key is pressed, so hopefully this will fix that. I'll report back.
Here
claude --versionreports2.1.83 (Claude Code)Is the fix to this issue supposed to be part of this version?
If yes: I don't think it works, I do not notice any difference with
before.
If no: I may have misunderstood your comment saying that "This should
hopefully resolve it in tomorrow's regular release".
Digging with Claude itself said that there is no newer version than the
one I have...
The most recent Claude Code changelogs doesn’t mention the fix .
For your reference, here is the link to the changelog:
https://code.claude.com/docs/en/changelog
Given the timing, it may be in the next one.
Hi definitely experiencing this on Windows, and I'll be happy to create a mailing list!
Thanks for the drive Maria. Amongother things I was unsure what to
favour in terms of communicaitonmeans, but a mailing list is perfectly
fine by me.
My email address: @.***
May be you would accept to share yours so that others can send theirs to
you provately?
Hi,
I confirm the issue is solved , at least partially: the cursor (on MacOS) is now properly recognized by VoiceOver and we can type and edit prompts in a much more reliable way.
However, I notice that when Claude Code uses a questionnaire workflow , or when prompting for tool authorization or any yes/no questions, the cursor seems stuck like it was before.
Could it be possible to make the fix implemented in 2.1.84 applied to the questions / config stuff?
I guett that a very basic rule like placing the cursor on the first character of the focused item would be great to have nearly. Perfect screen reader support.
Thanks
Yeah, good idea but I think this will need a dedicated issue, Yannick.
And to keep things simple I'd suggest that the issue is clearly limited
only to questions, for the moment.
Do you feel like opening it and referencingit back here so that we can
all comment and give thumbs?
Hi,
I can but not until tomorrow night. If someone else want to do this before, feel free :)
The core issue seems to be resolved, I can hear the characters I delete and navigate in the input box with controls like jump to previous or next word, etc. Thank you.
Just created #39900 to suggest that the cursor gets placed on the selected item in menus.
Again, thumbs up on the description of the issue and comments are more than welcome.
For those receiving this by e-mail the link to the new issue is:
https://github.com/anthropics/claude-code/issues/39900
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.