Repository navigation
Description
Environment
- OS: macOS
- Node Version: v22.23.2 and v26.0.0
- Package:
@clack/core(through@clack/prompts) - Package Version:
@clack/prompts1.8.1,@clack/core1.5.1, same on main (5ac9e73)
Describe the bug
When stdin ends while a prompt is waiting, or before it starts, the prompt never settles. await confirm(...) hangs, and in an ES module Node then exits with code 13 ("Detected unsettled top-level await"), with the cursor still hidden. It happens with closed stdin (< /dev/null, some CI runners and agent shells) and with piped input that runs out before the last prompt.
prompt() resolves only on submit and cancel (prompt.ts#L185-L196), and nothing handles the input stream ending.
To Reproduce
// repro.mjs
import { confirm, text, isCancel } from '@clack/prompts';
const ok = await confirm({ message: 'Continue?' });
console.log('confirm settled with', isCancel(ok) ? 'cancel' : ok);
const name = await text({ message: 'Name?' });
console.log('text settled with', isCancel(name) ? 'cancel' : JSON.stringify(name));$ node repro.mjs < /dev/null
◆ Continue?
│ ● Yes / ○ No
└
Warning: Detected unsettled top-level await at file:///.../repro.mjs:3
$ echo $?
13
$ printf 'y\r' | node repro.mjs
◇ Continue?
│ Yes
confirm settled with true
◆ Name?
│ _
└
Warning: Detected unsettled top-level await at file:///.../repro.mjs:5
$ echo $?
13
Expected behavior
The prompt settles when its input ends. Returning the cancel symbol seems the natural fit, since no answer can come and callers already handle isCancel(). With that, both runs above print "settled with cancel" and exit 0.
Additional Information
I've read #533 and the advice to skip prompts when there is no TTY. This is narrower: a prompt can still be reached with closed or piped stdin, and then it hangs with no message instead of cancelling. We hit it with @fumadocs/cli add in a non-interactive shell: it wrote the files, asked "Do you want to install with npm?", and exited 13 without installing anything.
I have a small fix in @clack/core with tests (cancel on the input's end, and right away if the input has already ended) and can open a PR if cancel is the behaviour you want.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNeeds triage
Activity
dreyfus92 commentedon Nov 9, 2026
hey @HardMax71, thanks for the clear repro and sorry this sat for a while. i can still see it on 1.9.0, both cases exit 13 for me. i'm wondering if cancelling when the input ends is the right call here, since callers already handle
isCancel(), and whether #623 is the way to go since it already has an approval. @43081j could you take a second look when you get a chance?HardMax71 commentedon Nov 9, 2026
@dreyfus92 yes, I'd keep cancel.
confirmdefaults to Yes (confirm.ts#L71), so settling with the default would answer "install with npm?" for the user, and throwing would break callers that only checkisCancel(). #623 is the fix I had in mind, so I won't open a separate PR.One gap in #623 and #624: when the input ends while an async
validateis still running, the answered prompt comes back as cancel. On main it submits.printf 'bob\r' | node async.mjsprintstext settled with "bob"on main andtext settled with cancelon both branches. With #623 the validator then finishes andonKeypressredraws the prompt as submitted, erasing the line the caller printed after it (prompt.ts#L266-L277).