Interactive password prompt broken when sudo-rs is invoked from non-standard PTY setups (e.g., kiro-cli)

[iiwaasnet]

When sudo-rs is invoked from kiro-cli (an AI coding assistant that executes shell commands), the interactive password prompt hangs —keystrokes are not properly transferred and raw escape sequences appear instead of typed characters. Classic sudo works fine in the same environment.

Steps to reproduce:

1. Run kiro-cli chat on Ubuntu 26.04
2. Have it execute sudo -k && sudo whoami
3. Password prompt hangs, input is garbled

Evidence:

• sudo -k && sudo whoami → hangs, no usable password prompt (sudo-rs 0.2.13)
• sudo.ws -k && sudo.ws whoami → works perfectly, password prompt appears and accepts input (classic sudo 1.9.17)
• Tested in multiple terminal emulators (kitty, built-in terminal) — same behavior
• On WSL2 with Ubuntu 25 (classic sudo), sudo works fine in the same tool

Expected behavior:

sudo-rs should handle the password prompt the same way classic sudo does, regardless of how the PTY is set up by the calling application.

Environment:

• sudo-rs 0.2.13-0ubuntu1
• Ubuntu 26.04 LTS
• Classic sudo 1.9.17 (works correctly)
• kiro-cli 2.2.0

Related:

• kiro-cli issue: sudo password prompt unusable in kiro-cli chat on Ubuntu 26.04 kirodotdev/Kiro#7997 (sudo password prompt unusable in kiro-cli chat on Ubuntu 26.04 kirodotdev/Kiro#7997)
• Related: sudo -v/-nv/-k/-K/-V/-h incorrectly reject environment variable arguments #1578

[bjorn3]

Quoting your comment on the Kiro issue tracker:

Raw escape sequences (e.g. [99;5u,
[27) appear instead of the typed characters

We don't use those raw escape sequences at all. The only control characters we use in the password prompt are BEL (if -B/--bell is passed) and BS (backspace, to erase feedback). Are they perhaps escape sequences emitted by kiro-cli that got interspersed by output from sudo-rs? How does kiro-cli handle subprocesses? Does it run them in a separate session+pty that it proxies? Does it run them in a separate session without controlling pty? Or does it run with the same pty attached while still trying to use the pty at the same time? If the last one, that is bound to lead to trouble even when you change stdio if the program uses /dev/tty (like og sudo and sudo-rs)

I won't be able to debug this locally myself. According to the docs, Kiro requires an account, and I don't want to accept any terms of service for AI things.

[iiwaasnet]

We don't use those raw escape sequences at all. The only control characters we use in the password prompt are BEL (if -B/--bell is passed) and BS (backspace, to erase feedback).

I am not sure those symbols have any specific meaning, i just saw some of those trying to type the password in sudo prompts in kiro-cli.
In general, i am not able to answer any of those questions as i am just a user of kiro-cli.

[squell]

What happens if you use kiro-cli with ogsudo with Defaults pwfeedback enabled in /etc/sudoers? sudo-rs and ogsudo are aligning on the codepath taken for passwords with the next release of ogsudo and I am guessing similar artefacts will be seen there (or else with the next upcoming release of ogsudo). The password entry routine in sudo-rs is based on that in ogsudo.

[iiwaasnet]

Tested with Defaults pwfeedback enabled in /etc/sudoers.d/ using classic sudo (1.9.17) from within kiro-cli (2.3.0):

Result: Authentication works — password is accepted and sudo whoami returns root. However, the visual feedback is broken.

Observed behavior (consistent across multiple attempts):

• Only a single * ever appears, regardless of how many characters are typed
• The asterisk overwrites the [ at position 0 of the prompt line, so it renders as:

*sudo] password for user:

instead of showing asterisks after the colon

• The actual password input buffer works correctly underneath — authentication succeeds every time

Without pwfeedback: classic sudo works perfectly in kiro-cli — prompt appears cleanly, password is accepted, no visual artifacts.

So there is indeed some interference with the feedback rendering in this PTY setup, but it doesn't break authentication like sudo-rs does (where the prompt hangs completely and input is garbled/unusable).

[3v1n0]

Can you see if #1591 or #1592 can help with this?