Sudo Password Lock Glyph Is Now a Blinking Block

[Mimisor7]

Issue Description

When I try sudoing in ghostty it no longer shows a lock glyph and now shows a standard blinking block. I have no additional settings set in config and I don't know what I did that changed this because when I first installed this I liked that it had a lock glyph when prompted to input passwords.

Screencast.From.2025-11-12.01-29-01.mp4

Expected Behavior

When using sudo with default settings, it should show a glyph of a lock.

Actual Behavior

When using sudo with default settings, it shows a blinking block.

Reproduction Steps

1. Open Ghostty. 2. Type in any sudo command

Ghostty Logs

No response

Ghostty Version

Version
  - version: 1.2.3
  - channel: stable
Build Config
  - Zig version   : 0.14.1
  - build mode    : builtin.OptimizeMode.ReleaseFast
  - app runtime   : apprt.Runtime.gtk
  - font engine   : font.main.Backend.fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.17.0-6-generic
  - desktop env   : other
  - GTK version   :
    build         : 4.20.1
    runtime       : 4.20.1
  - libadwaita    : enabled
    build         : 1.8.0
    runtime       : 1.8.0
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

Ubuntu 25.10 (Questing Quokka)

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

GNOME 49.0

Minimal Ghostty Configuration

Default, No additions in config

Additional Relevant Configuration

I installed the unofficial Ubuntu Ghostty package using https://github.com/mkasberg/ghostty-ubuntu/
I have an Nvidia GPU and I use proprietary Nvidia drivers.

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[Mimisor7]

ghostty/src/renderer/generic.zig

Line 1132 in 05b5809

const cursor_style = if (state.terminal.flags.password_input)

This part of the code is responsible, it seems to me that state.terminal.flags.password_input isn't being detected or is the wrong value. Was it a sudo-rs update that caused this?

[rhodes-b]

Id say that is probably likely.

There isn't a guaranteed way for ghostty to know on linux at least that something is requesting a password like sudo so it has to use some heuristics to assume when to display the lock icon, if the program isnt meeting those requirements ghostty will not draw the lock

https://github.com/ghostty-org/ghostty/blob/main/src/termio/Exec.zig#L364-L366

[elcste]

Was it a sudo-rs update that caused this?

There was a recent update to sudo-rs in 25.10:

rust-sudo-rs (0.2.8-1ubuntu5.2) questing-security; urgency=high

  * SECURITY UPDATE: multiple security fixes (LP: #2130623)
    - debian/patches/lp-2130623-GHSA-q428-6v73-fc4q-*.patch
    - debian/patches/lp-2130623-GHSA-c978-wq47-pvvw-*.patch
    - CVE numbers pending

 -- Simon Johnsson <simon.johnsson@canonical.com>  Mon, 10 Nov 2025 16:12:00 +0100

[pluiedev]

I suspect this is an issue with sudo-rs. Terminal emulators do not have a 100% reliable way of detecting when password input is required, and sudo-rs is likely deviating from the heuristics we expect here. Please also make an issue upstream so we could coordinate this better.