[BRLTTY] Claude Code not using the native terminal's cursor

[Sébastien Hinderer]

Hello,

Nicolas Pitre (2026/03/25 23:46 -0400):
> On Fri, 20 Mar 2026, Sébastien Hinderer wrote:
>
> > I can imagine that BRLTTY could cope with such simulated cursors but
> > it's not really satisfactory.
>
> BRLTTY version 6.9 already contains support for this:
>
>     When enabled via the "Soft Cursor Detection" preference, BRLTTY will
>     detect a soft cursor by finding screen cells with a unique
>     background color.
>
>     The feature is disabled by default and can be enabled in the
>     Navigation submenu of the preferences menu.
>
> Note that this is a best effort solution. If for example you quit Claude
> Code and restart another Claude Code session without clearing the screen
> content in between then you may end up with two "soft" cursors drawn on
> the screen and BRLTTY will not consider them due to the ambiguity. Or
> BRLTTY will continue to track the Claude Code cursor after you quit it
> if the real cursor ends up on the first column. Better be aware.
> The workaround is easy: always clear the screen when quitting claude.

I was not aware of this, thanks!

> > Also, I am under the impression that, as much as Claude Code has a
> > colorblind friendly mode, it could also have a screen reader friendly
> > mode where it wouldn't use that many embllishment character and perhaps
> > also have a more linear presentation, wiht less popping messages.
>
> If you are feeling advanturous you could investigate alternative agents
> that support Claude (and often many other AI models), such as Aider or
> Cline. I didn't explore any of those possibilities but maybe some of
> them are more accessibility-friendly, or even Open Source and therefore
> fixable by yourself.
>
> Personally I find the above BRLTTY feature sufficient for my tolerance
> level with Claude Code.

For completeness, the issue of Claude Code not putting the cursor at the
right place in the prompt has now been fixed upstream.

> Oh, and I contributed patches to the kbd package so that Shift+Tab is
> properly supported on the linux console. No idea when it'll trickle down
> into distros though.

Does the patch bind shift-tab to the ESC[Z sequence?

I defined a bunch of such sequences locally sothat become usable from
within Emacs.