# v2.40.0 — the tool that said yes and did nothing

**Released 2026-09-24.** Upgrade:

```sh
sudo snap refresh yazses     # snap
pipx upgrade yazses          # or: uv tool upgrade yazses
scoop update yazses          # Windows
```

## If you are on Debian or Ubuntu, this release is the one that matters

Since v2.39.0, dictation on Debian and Ubuntu Wayland was transcribed correctly and
then typed **nothing**. The daemon log said `Injecting 21 chars, 2 words.` and the
screen stayed empty. `yazses doctor` said `[OK] Injection: ydotool` and
`▲ Good to go`.

ydotool 1.x and ydotool **0.1.x** are different command-line tools wearing the same
name. Debian and Ubuntu ship 0.1.8 — that is the version in Ubuntu 24.04 through
26.04. YazSes spoke only 1.x:

```console
$ ydotool type -d 6 -H 6 -- hello
ydotool: type: error: unrecognised option '-d'
$ echo $?
0
```

That exit code is why this was silent rather than merely broken. `check=True` never
raised, so the clipboard fallback never fired, nothing reached the log, and doctor had
nothing to report.

### Why v2.39.0 was where it started

v2.39.0 fixed socket discovery: ydotoold 0.1.8 ignores `--socket-path` and binds
`/tmp/.ydotool_socket`, so YazSes learned to look there. That fix is correct in
itself. But it made ydotool *selectable* on Debian and Ubuntu for the first time, and
ydotool is first in the backend order — so it displaced a path that had been working.

**A fix that makes a backend reachable makes it load-bearing.** The probe was right
and the backend behind it had never been exercised on those machines.

### Three command lines, all wrong, all silent

| What YazSes sent | What ydotool 0.1.x did |
|---|---|
| `type -d 6 -H 6` | refused it; 0.1.x spells it `--key-delay` and has no hold time |
| `key 29:1 47:1 …` | 0.1.x wants **symbolic** names, and has no error path at all |
| `key 97:0` | typed the digit `9` — on **every** hold-end |

That last one is the stuck-modifier guard, which runs after every burst. And because
0.1.x's `key` falls back to the first character of a name it does not recognise,
`Return` — what "new line" sends — typed the letter `r`, `Escape` typed `e`, and
`KEY_BACKSPACE` typed `k`.

### What changed

YazSes now detects which ydotool is installed and speaks its dialect. It classifies
ydotool's **stderr** rather than believing its exit code, so a refused command line
reaches the clipboard fallback instead of vanishing. A key that 0.1.x cannot express
raises rather than typing a wrong character. Falling back to the clipboard is logged
at WARNING, because this whole failure was invisible. And `yazses doctor` now names
the dialect it found:

```
[OK] Injection: ydotool 0.1.x — works on any Wayland compositor (Debian/Ubuntu's
     older CLI: typed with --key-delay and symbolic key names; the key-up flood
     guard 1.x offers is not expressible here)
```

**If you are on ydotool 1.x** — Arch, Fedora, or a source build — nothing changes:
the command lines YazSes sends you are byte-for-byte what they were, and a test now
pins them against the help text upstream v1.0.4 actually prints.

## Also in this release

- **Windows can paste instead of typing.** `[injection] backend = "clipboard"` now
  works on Windows, for applications that receive the right *number* of characters
  with every one of them wrong — rows of `?`, `-` or `.`. Off by default.
- **`[injection] backend` was ignored on Windows.** The setting was read, validated
  and then overridden. The one platform where the alternative is the documented
  remedy was the one platform that could not choose it.
- **`yazses inject --delay` and `--diagnose`**, so you can test injection into the
  application you actually care about rather than into the terminal you typed in.
- **A face you hold instead of a key you press** — opt-in, off by default.
- A contributor's one-line cask fix that could only ever have been reverted.