bad terminal hard cursor placement

Resolved 💬 4 comments Opened Apr 29, 2025 by npitre Closed Dec 15, 2025

Environment

  • Platform (select one):
  • [x] Anthropic API
  • [ ] AWS Bedrock
  • [ ] Google Vertex AI
  • [ ] Other: <!-- specify -->
  • Claude CLI version: <!-- output of claude --version --> 2.0.37 (Claude Code)
  • Operating System: <!-- e.g. macOS 14.3, Windows 11, Ubuntu 22.04 --> Fedora 42
  • Terminal: <!-- e.g. iTerm2, Terminal App --> Linux VT console

Bug Description

Claude Code renders a visual cursor using styling (inverted space character)
but leaves the hardware cursor positioned elsewhere (typically at the
bottom-left of the interface). Assistive technologies like BRLTTY track the
hardware cursor position, not visual styling, because:

  1. Hardware cursor position is queryable via terminal APIs
  2. This is the standard mechanism for unambiguous cursor tracking in

terminal accessibility

Current Impact

Current workaround required:

  • Disable cursor tracking in BRLTTY to prevent the braille window from jumping on every redraw
  • Text editing is nearly impossible since the cursor location isn't trackable during input
  • The vim integration for prompt editing helps but doesn't solve the underlying cursor tracking issue

Status: Usable but significantly degraded for braille display users.

Technical Details

Example escape sequence output when typing at the prompt:

^[[2K^[[1G^[[38;5;248m┃^[[0m ^[[38;5;139m❯^[[0m ^[[7m ^[[0m^M
^M
^M

Breaking this down:

  • ^[[2K - Clear line
  • ^[[1G - Move cursor to column 1
  • ^[[38;5;248m┃^[[0m - Styled border character
  • ^[[38;5;139m❯^[[0m - Styled prompt character
  • ^[[7m ^[[0m - Inverted space (visual cursor)
  • ^M^M^M - Newlines that move the hardware cursor away from the input area

The hardware cursor ends up positioned away (e.g., 3 lines below) from where
the visual cursor is rendered, causing assistive technology to lose focus on
the actual input location.

Expected Behavior

The hardware cursor should be positioned at the visual cursor location
(input prompt, selection indicators, etc.) after rendering, making the
interface fully accessible to braille displays and other assistive
technologies without compromising the visual experience for sighted users.

Examples of Correct Behavior

Several TUI applications handle this correctly:

  • lynx (web browser) and alpine (email client): Both have options

to position the hardware cursor at visual indicators after redrawing

  • gh (GitHub CLI): Uses dynamic lists and selection indicators while

keeping the hardware cursor positioned at those indicators

Proposed Solution

Position the hardware cursor at the visual cursor location after each screen
redraw. This could be implemented as:

  1. Default behavior change (recommended): Always position hardware cursor

at visual cursor

  1. Configuration option: Add --hardware-cursor flag or config file

setting

The hardware cursor can be made invisible via ANSI sequences for sighted
users while remaining trackable by assistive technology.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗