[johnpangalos]

The bug

wt update could not be confirmed anywhere. In a normal interactive terminal:

wt update
wt v0.4.0 → v0.5.0
aborted.

No question is ever asked, and the exit code is 0.

promptYes opened the /dev/tty file descriptors and wrapped them in tty.ReadStream / tty.WriteStream. Under Bun 1.3.13 on macOS, new WriteStream(fd) on a tty fd throws:

EINVAL: invalid argument, kqueue
      at WriteStream (internal:fs/streams:244:58)
      at new WriteStream (node:tty:42:36)

ReadStream constructs fine; only WriteStream fails. That throw landed inside the same try block that guards the open, whose catch returned false — the same false that means "the user typed n". So the question was never written, and its absence was reported as a refusal.

The same catch-all also swallowed the legitimate no-terminal case (ENXIO, under a pipe or a CI step), making a genuinely unanswerable prompt indistinguishable from a declined one.

Introduced by 217550f, which moved the prompt off stdio onto /dev/tty so it would survive a piped stdout.

The fix

That goal is kept — the fds are still /dev/tty, so a piped stdout is still fine — but writeSync/readSync talk to them directly instead of through node:tty. The terminal stays in canonical mode, so the kernel echoes what is typed and returns one line per read, which is all a y/N question needs, and neither call has the kqueue failure mode. node:tty and node:readline/promises are gone from update.ts.

promptYes now returns "yes" | "no" | "no-tty" rather than a boolean, so a real absence of a terminal is reported as itself:

wt update
wt v0.5.0 → v99.0.0
wt: no terminal to confirm on — re-run with: wt update --yes

and exits 1. Only a real "n" still prints aborted. and exits 0.

wt update gains -y/--yes to skip the prompt, which is what makes that message actionable. Unknown flags are rejected rather than silently ignored.

Tests

The newer-version path had no test at all, which is how this shipped: the existing wt update tests cover only "up to date" and "gh missing", both of which return before the prompt.

bun test cannot allocate a pty, so it cannot reach the failing line — which is exactly why the bug survived. The regression is therefore guarded where a pty does exist: the macOS CI job drives the real compiled binary under script(1). From the run on this branch:

wt v0.5.0 → v99.0.0
install? [y/N] aborted.

The question reaches the terminal, n is read from it, and the abort is a real answer rather than a swallowed exception. The step also asserts --yes neither prompts nor demands a terminal:

wt v0.5.0 → v99.0.0
INSTALLED

Three unit tests cover what bun test can reach: the no-tty refusal, --yes installing and recording the tag, and an unknown flag.

🤖 Generated with Claude Code