You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 1587b41
Browse filesBrowse the repository at this point in the historyBrowse files
The Output setting chooses where the generated value goes: typed at the cursor
as before, copied to the clipboard only, or both. A key configured before this
existed carries no setting and keeps typing.
Copying is done through the platform's own helper - clip.exe, xclip or wl-copy,
pbcopy - reached by the same Shell helper the typing path uses, so the value
travels on stdin and never appears in a process list. That helper is now shared
rather than duplicated inside KeyboardTyper.
The clipboard is written before the value is typed. Typing is the half that can
fail on a missing helper, and having the value on the clipboard is what makes
that recoverable instead of a lost password.
Fixes an encoding bug found by testing the real clipboard rather than a
substitute: CliWrap's PipeSource.FromString defaults to Console.InputEncoding,
the ANSI code page on Windows, so anything outside it arrived mangled -
"pässwörd-üñî" came back as "p?ssw?rd-???". The encoding is now stated as UTF-8.
This was not only a clipboard problem: the Linux typing path pipes through the
same helper into 'xdotool type --file -', which expects UTF-8, so a non-ASCII
password would have been typed wrongly there too.
Covered by unit tests over the three modes, the ordering, the pre-existing
settings case and a failing clipboard, plus integration tests that round trip
real values - symbols and non-ASCII included - through the actual clipboard and
put its previous contents back. Linux typing re-verified in a container.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments