Cursor Style Interference: Claude Overrides Terminal Cursor Behavior

Thanks for the feedback! We do not support inferring terminal cursor styles at the moment. We may look into it in the future.

If I understand @felixbuenemann's original message correctly, the problem here is more about the current cursor styling being confusing because it doesn't change when the terminal that Claude is running in is active.

Personally, I don't have a strong preference for what the specific styles are, but it would be really helpful for the active and inactive terminal cursors to at least be different from each other. I'm also constantly typing into the wrong tab because I think Claude is active.

The active/inactive cursor styling is just a subset of cursor styling that a user's terminal may be applying. E.g. I have:

• block for normal mode in zsh vi-mode
• beam for insert mode in zsh vi-mode
• underscore for replace mode in zsh vi-mode
• outline block for inactive terminals

claude-code should either not override these settings, or allow configuration for all of these.

This same issue is for me. Except, my impact is a little different. I use a dark cursor with reversed font color. My font is white. When I move the cursor into the claude window and then back to the terminal or nvim window, the cursor block is now white with white font. White on white makes the letter within the cursor block illegible.

UPDATE: My issue seems to only manifest when I am using Windows Terminal. When I use mintty the issue does not happen. There seems to be an open issue with WT regarding the way the conpty is working, but not sure if this issue is on the Claude Code or WT side.

If I understand @felixbuenemann's original message correctly, the problem here is more about the current cursor styling being confusing because it doesn't change when the terminal that Claude is running in is active. Personally, I don't have a strong preference for what the specific styles are, but it would be really helpful for the active and inactive terminal cursors to at least be different from each other. I'm also constantly typing into the wrong tab because I think Claude is active.

This is a super annoying issue for me! Has anyone found a workaround?

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This is still an issue! Remove autoclose (as if this would work — #16497)

Removing the autoclose label won't prevent autoclosing. Currently, due to the https://github.com/anthropics/claude-code/issues/16497 bot misconfiguration, any issue that gets the "This issue has been inactive for 30 days" warning will be closed after another 30 days.

It would be helpful to have color customization options in Claude Code's settings to make different parts of the conversation more visually distinct.

Use Case:
Currently, user input can be difficult to distinguish from Claude's responses and other CLI output, especially in longer conversations. Being able to customize colors would improve readability and make it easier to scan through conversation history.

Proposed Solution:
Add a colors section to ~/.claude/settings.json with options like:

{
"colors": {
"userInput": "#00FF00",
"assistantResponse": "#FFFFFF",
"systemMessages": "#888888",
"toolOutput": "#FFFF00",
"errors": "#FF0000"
}
}

Or support for named terminal color codes (0-15) to work with existing terminal themes:

{
"colors": {
"userInput": 10,
"assistantResponse": 15
}
}

Alternative:
Even just a simple boolean flag like "highlightUserInput": true that makes user input bold or uses a distinct color would be a helpful first step.

Benefit:
This would allow users to customize Claude Code to match their preferences and terminal themes, improving the overall UX without requiring changes to terminal emulator settings.

I too have this issue. My terminal has configured a | cursor but sometimes when exiting claude via CTRL-C it resets the terminal session's cursor to █. It restore the cursor to what it was before launching on exit.

+1 on this. Related request: it would be great if Claude Code's vim mode could also change the cursor shape based on the current mode — block for Normal, bar/line for Insert, underline for Visual — using standard ANSI escape sequences (\e[2 q for block, \e[6 q for bar, etc.). This is the primary visual cue vim users rely on to identify the current mode at a glance. Right now the cursor stays as a block in all vim modes, which makes it hard to tell which mode you're in without checking the status indicator.

+1 on this. Related request: it would be great if Claude Code's vim mode could also change the cursor shape based on the current mode — block for Normal, bar/line for Insert, underline for Visual — using standard ANSI escape sequences (\e[2 q for block, \e[6 q for bar, etc.). This is the primary visual cue vim users rely on to identify the current mode at a glance. Right now the cursor stays as a block in all vim modes, which makes it hard to tell which mode you're in without checking the status indicator.

Exactly this. I filed #26231 specifically for the vim mode caret shape issue - the cursor stays as a block in both INSERT and NORMAL mode, which breaks a fundamental vim UX pattern.

For me this makes vim mode essentially unusable - after decades of vim, judging the current mode by cursor shape is pure muscle memory. Having to glance at the status indicator every time completely breaks the flow.

I traced it through the source - the mode transitions (enterInsert/exitInsert in the nfq hook) already track and propagate the mode state correctly, they just never emit the ANSI cursor shape sequences. The fix is literally two process.stdout.write() calls:

• \x1b[6 q (steady bar) on entering INSERT
• \x1b[2 q (steady block) on entering NORMAL

This was previously reported as #13924 but was auto-closed as a duplicate of #10215, which is about text color - unrelated.

A simple option in settings.json like cursorStyle: beam | block | inherit would solve this for me. inherit should be the default.

Adding a data point: OpenAI Codex CLI correctly handles cursor blinking and focus-based cursor visibility, while Claude Code does not. This makes it easy to compare expected vs actual behavior side-by-side.

Specific observations (iTerm2 + tmux, Linux remote):

1. Cursor blinking: Codex respects the terminal's blink setting. Claude Code forces a steady (non-blinking) block cursor.

1. Focus-out cursor hiding: When switching away from the terminal tab, Codex's cursor disappears (respecting iTerm2 focus events). Claude Code's cursor stays visible and unchanged.

1. tmux multi-pane interaction: With focus-events on, switching between tmux panes correctly shows/hides Codex's cursor per pane. Claude Code's cursor remains a steady block in all states — active, inactive, focused, unfocused.

The Codex CLI demonstrates that a TUI application can properly integrate with terminal cursor settings and focus events. Would be great to see Claude Code match this behavior.

Environment: iTerm2 → SSH → tmux 3.4 → Claude Code / Codex

A simple option in settings.json like cursorStyle: beam | block would solve this for me.

Don't forget underline and thickness.

Yes, all cursor options should be reset when Claude is closed. It seems that this feature is already in place but it's not always working.

Currently I do a workaround in zsh to manually reset my cursor on every prompt:

_reset_cursor() { printf '\e[6 q'; }
precmd_functions+=(_reset_cursor)

For me, the cursor is a solid block (correct) before I start Claude Code, a solid block while I'm using it (also correct) but a blinking block afterwards (horrendously distracting).

I needed to tweak the code @silverwind posted (thanks! that fixes issues I'm having with other programs, too!) to make the escape sequence \e[2 q in order to get a solid block.

Thanks for the feedback! We do not support inferring terminal cursor styles at the moment. We may look into it in the future.

A year later… and still nothing’s changed. Starting to feel like that “we’ll look into it” was just an April Fools’ joke ☹️

This issue is particularly impactful for CJK (Chinese/Japanese/Korean) IME users.

When Claude Code overrides the cursor to a block style, Korean IME inline composition breaks — each syllable must be fully committed before the next one can be typed, instead of composing naturally. This makes typing in Korean extremely painful during Claude Code sessions.

Environment:

• Terminal: Ghostty (macOS)
• Terminal config: cursor-style = bar (beam cursor)
• Claude Code forces block cursor via DECSCUSR, ignoring terminal preference
• No env var or config option exists to disable this behavior

Impact: This is not just a cosmetic preference — it's a functional input barrier for CJK language users. Korean, Japanese, and Chinese input methods rely on inline composition where the cursor style affects how the IME renders intermediate states.

Request: Please add an option (env var like CLAUDE_CODE_DISABLE_CURSOR_CHANGES=true or a config setting) to respect the terminal's native cursor style.

Instead of adding a configuration option for this, it should simply be the default. There’s no real reason for Claude to define or modify the cursor in the first place—it should behave opaquely and leave the terminal’s cursor handling unchanged.

Similar issue here over SSH with Alacritty 0.16.1 on Linux (Arch).

But when running Claude Code over SSH, the cursor completely disappears when the terminal
window loses focus. The expected behavior is a hollow (outline) cursor on unfocus, which
works correctly:

• In any local terminal (no SSH)
• In SSH sessions without Claude Code running (e.g. plain bash, sleep, etc.)

This confirms Claude Code is overriding the cursor style and not restoring it,
preventing Alacritty from drawing its unfocused hollow cursor.

The TERM value (alacritty vs xterm-256color) makes no difference — the issue is Claude
Code's cursor manipulation itself.

Environment:

• Terminal: Alacritty 0.16.1
• OS: Arch Linux (EndeavourOS)
• Connection: SSH
• Claude Code: 2.1.90

Please address this. I have a very tough time seeing where my focus is, even with tmux altering the display of the active pane. I am now just killing claude code regularly in order to avoid having multiple cursors show up. This is why I tend to prefer open source tools like aider or crush, but Claude Code is the best; I'd rather not dump it just because devs won't fix a very easy problem.

Update: Found a workaround for the invisible cursor over SSH.

Setting FORCE_COLOR=1 before launching Claude Code makes the cursor visible again in SSH sessions. Tested with Alacritty 0.16.1, kitty and foot (with foot-terminfo) on Arch Linux (Wayland/KDE).

To make it persistent over SSH, add to client ~/.ssh/config:

Host myhost
    SetEnv FORCE_COLOR=1

And on the server in /etc/ssh/sshd_config:

AcceptEnv FORCE_COLOR

Limitations:

• This is a workaround, not a fix — Claude Code should handle cursor rendering correctly over SSH without needing this
• No hollow/outline cursor on unfocus — the active/inactive distinction is still broken
• TERM=dumb does not help

Summary of testing:

• Cursor invisible over SSH: Alacritty, kitty, foot — all affected regardless of terminfo
• Cursor works fine locally on the same machine
• ssh -t makes no difference
• FORCE_COLOR=1 restores cursor visibility over SSH

Environment: Arch Linux, KDE/Wayland, Claude Code 2.1.90+, SSH

+1 — reproducing on Ubuntu 24.04 with Ghostty (cursor-style = bar). Claude Code's TUI forces a steady block cursor via DECSCUSR, overriding terminal config. Would love a cursorStyle: "inherit" option in settings.json.

Just got into Claude Code with Jetbrains IDEs and Claude plugin.

So far this thing is most annoying and frustrating experience with Claude Code.

I'm constantly typing in code window instead of terminal because there is 0 visual clues what's focused now, solid cursor bar always shown...

How difficult can this be? Please!

How difficult can this be? Please!

The fix is straightforward:

1. Stop rendering the cursor as a reverse-video inline block
2. Show the terminal's native hardware cursor at the same position
3. The terminal emulator handles focus states automatically (solid = active, hollow = inactive)

This works in every terminal that follows standard cursor conventions (iTerm2, Ghostty, Kitty, etc.).

Example extension for Pi
https://github.com/ineersa/my-pi/blob/main/packages/extensions/extensions/focus-cursor.ts

Meanwhile after a year later it's still a thing, constant frustration.

This is the behavior of the underlying CUI library (ink) at work, so there is probably little claude-code can do about it.

Meanwhile, I wrote a small general-purpose terminal filter that can strip the fake cursor ink emits.
https://github.com/knu/tfil

OMG, works like a charm! Thank you so much, @knu

Why is this closed as completed? It was not fixed.

oh wow what a shitshow. lets use opencode

@chrislloyd My earlier comment was about a workaround, a quite elaborate one at that. It requires running the claude executable as a child process of another program (tfil). In no way is this issue closed. A workaround is not a fix. If anything, Anthropic should consider incorporating the general approach employed by tfil.

@chrislloyd is this fixed in an upcoming build? If not would you please open this for consideration, as the issue persists.

Yes, @chrislloyd, seconding the request to reopen this.

Fixed in Windows Terminal since the last update

Still reproduces in other terminals, so the Windows Terminal fix doesn't cover them**

The current resolution doesn't hold for other terminal emulators. On Git Bash, WezTerm (Windows 10, Git Bash), the input cursor still flickers during screen redraws:

• while Claude is animating (the working/thinking spinner and during response streaming), and
• while scrolling the terminal (scrollback).

The cursor is steady only when the UI is idle. prefersReducedMotion: true reduces the spinner-driven part, but does not eliminate the flickering during the streaming/scroll. WezTerm with cursor_blink_rate = 0 and default_cursor_style = 'SteadyBlock' does not suppress it. It is independent of editorMode (both vim and normal reproduce).

Since the flicker is only masked by a Windows Terminal update and was not fixed in Claude Code, every non “Windows-Terminal emulator is still affected. This points to the root cause being Claude Code re-emitting cursor show/hide (ESC[?25l / ESC[?25h) on each redraw frame. Hiding the cursor once for the duration of a redraw/stream and restoring it afterward would fix it across all terminals, not just Windows Terminal. Could this be handled in Claude Code itself (or the issue reopened)?

Environment: Windows 10 (build 19045), WezTerm + Git Bash (MSYS), Claude Code on the latest channel.