11 min read
A Node.js readline silent exit happens when rl.question() never fires its callback. The interface closes first, the awaited promise stays pending forever, and the event loop drains. As a result, the process exits cleanly with status 0 — mid-prompt, no error, no stack trace. I hit this in three separate places in sarvam-cli, an MIT-licensed agentic coding CLI. The fix is eight lines. The interesting part is what each call site should do when input ends, and why “decline” is the only safe answer at an approval prompt.
Table of Contents
- TL;DR
- The Symptom: a % at the End of a Terminal Paste
- Why My First Diagnosis Was Wrong
- What Actually Causes the Node.js readline Silent Exit
- Why Exit Code 0 Is the Real Damage
- Three Call Sites, One Copy-Pasted Habit
- The Fix: Resolve to a Sentinel When the Interface Closes
- What null Should Mean at Each Call Site
- Why a Partial Write Is Worse Than No Write
- Proving It: Testing the Interactive Path in a pty
- Quick Reference
- Beyond Node: Any Callback With a Path That Never Runs
- CISSP Domain Mapping
- Key Takeaways
- Try sarvam-cli
TL;DR
rl.question()never fires its callback if the readline interface closes first. Ctrl+D, Ctrl+C, and exhausted piped stdin all close it.- A pending promise is not a running task. Node finds nothing scheduled, drains the loop, and exits with status 0 — so the failure presents as success.
- The fix is to resolve to
nullon close, not to reject. End of input is normal, not exceptional. - What
nullmeans differs per call site: exit at a REPL prompt, decline at a consent gate, abort without writing in a config wizard. - At an approval prompt,
=== "y"fails closed and!== "n"fails open. Same line count, opposite blast radius. - Test the interactive path in a pseudo-terminal. Piping only exercises the non-TTY code path, and your users are on the other one.
The Symptom: a % at the End of a Terminal Paste
Someone sent me a session transcript from sarvam-cli. The last four lines:
❯ /model
Current model: sarvam-105b
Available: sarvam-105b
model> %
That trailing % is zsh telling you the previous command produced output with no final newline. Specifically, it only appears when zsh has regained control — which means the process exited. While sitting at a prompt. Having printed model> and then simply stopped existing.
No error. No traceback. Nothing in the logs.
Why My First Diagnosis Was Wrong
My first theory was wrong, and it is worth saying so. I assumed stdin contention. The code attached a raw process.stdin.on("data") listener for a Ctrl+O keybinding while a readline interface was consuming the same stream. Two readers, one pipe — a classic. I wrote it up confidently.
Then I reproduced it before fixing it, and the theory collapsed. The /model flow completed perfectly. Additionally, the line buffer survived a mid-line keypress intact. Whatever killed the process, it was not stdin contention.
What Actually Causes the Node.js readline Silent Exit
Here is the code every Node CLI writes to get an async prompt:
const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
const ask = (q) => new Promise((resolve) => rl.question(q, (a) => resolve(a)));
const name = await ask("Your name: ");
rl.question() registers a one-shot callback for the next line of input. That is the whole contract. Consequently, there is exactly one way for it to never be called: the interface closes before a line arrives.
Three ordinary things close it:
- Ctrl+D — EOF at the terminal
- Ctrl+C — readline’s default SIGINT behaviour closes the interface
- Piped stdin running out of lines —
printf 'a\nb\n' | sarvamwhen the CLI asks five questions
When any of those happen, the callback is dropped. The promise attached to it stays pending. await never returns.
Now the part that turns a bug into a silent bug. A pending promise is not a running task. Node does not wait on it, because nothing is scheduled — no timer, no socket, no handle. The event loop finds itself with nothing to do, and does the correct thing:
It exits. Status 0.
From the outside, your program reported success. From the inside, it never finished the line it was on.
$ printf '\n\n\n' | sarvam --init
sarvam init
----------------
Provider [a/b] (default: a): API key: $ echo $?
0
Success. Nothing written.
Why Exit Code 0 Is the Real Damage
A crash is loud. You get a stack trace, a non-zero status, and CI goes red. This is the opposite. It is a false success, and false success is the failure mode that survives longest in production, because nothing is watching for it.
That gap between “the process succeeded” and “the product worked” is exactly the product quality vs code quality split — no test suite in this repo was wrong, and every one of them passed.
Concretely, in my case:
sarvam --init && echo "configured" && deploy.sh
--init exits 0 having written no config file. However, the && chain proceeds anyway. Then deploy.sh runs against a machine that was never configured. The one signal a shell script has for “did this work” was lying.
Three Call Sites, One Copy-Pasted Habit
Once I understood the mechanism, I grepped for the shape rather than the symptom — rl.question wrapped in a new Promise. It appeared three times.
1. The main REPL prompt. Ctrl+D exited silently. In practice, this is the one everyone would eventually notice and shrug at, because “Ctrl+D quits” looks like intended behaviour when the process disappears.
2. A nested sub-prompt. The one in the transcript. Identical cause, more visible, because it left a half-drawn prompt on screen.
3. The --init configuration wizard. The worst of the three, and the one nobody would have found by hand. Specifically, it only misbehaves under piped stdin — which is exactly how CI and setup scripts drive it.
Same eight lines, copy-pasted, three times. That is the honest reason it appeared three times: not three bugs, one habit.
The Fix: Resolve to a Sentinel When the Interface Closes
Resolve to null when the interface closes, so every caller gets a value instead of hanging:
let closed = false;
rl.on("close", () => {
closed = true;
});
const ask = (q: string): Promise<string | null> =>
new Promise((resolve) => {
if (closed) return resolve(null);
let answered = false;
const onClose = () => {
if (!answered) {
answered = true;
resolve(null);
}
};
rl.once("close", onClose);
rl.question(q, (a) => {
answered = true;
rl.removeListener("close", onClose);
resolve(a);
});
});
Three details matter more than they look:
resolve(null), notreject(). End of input is not exceptional. It is the normal way a pipe finishes and the normal way a user quits. Rejecting forces every call site into atry/catchand tempts people to swallow it.- The
answeredguard. Without it, a close event firing after a legitimate answer double-resolves. That is harmless with promises, but it hides ordering bugs. removeListeneron the success path. A long REPL session asks hundreds of questions. Without this you accumulate a close listener per prompt, and Node starts warning you about a leak around 11.
What null Should Mean at Each Call Site
This is where a mechanical fix becomes a design decision. null means “input ended.” What you should do about that differs at every call site. Furthermore, getting it wrong at one of them is a security bug.
At the main prompt — exit cleanly.
const input = await ask("❯ ");
if (input === null) break; // fall through to the normal shutdown path
At an approval prompt — decline. Always.
const ans = await ask(`▸ ${tool}: ${summary} [y/N] `);
if (ans === null) return false; // stdin closed — never assume consent
return ans.toLowerCase().trim() === "y";
This is the one that matters. sarvam-cli is an agentic assistant that can run shell commands and write files, gated behind a [y/N] prompt. Therefore, “input ended” must never be read as approval.
Note how easily it goes the other way. Had the original been written as a denial check:
return ans.toLowerCase().trim() !== "n"; // looks equivalent. isn't.
…then an empty or absent answer becomes approval, and a closed stdin auto-approves every pending action. Same number of lines, opposite blast radius. Fail-closed is not a philosophy here. It is a comparison operator — and it is the most concrete example of cybersecurity architecture principles I have shipped in one line of code.
Why a Partial Write Is Worse Than No Write
In the config wizard — abort without writing.
const answers: string[] = [];
for (const q of questions) {
const a = await ask(q);
if (a === null) {
rl.close();
console.error("\n init aborted — input ended before every question was answered.");
console.error(` Nothing written to ${CONFIG_PATH}.\n`);
return null; // caller exits non-zero
}
answers.push(a);
}
The tempting alternative is to save whatever you collected. Don’t. In this codebase a partial config with an empty apiKey field is worse than no file at all, because of a second bug it interacts with:
// The config file wins over the environment...
const apiKey = file.apiKey ?? process.env.API_KEY ?? "";
?? only falls through on null/undefined. An empty string is a defined value. As a result, a config file containing "apiKey": "" permanently shadows the environment variable. Export API_KEY all you like — the CLI reports “no API key found” forever, and the file causing it looks empty and harmless.
A partial write turns a clean failure into a persistent one. No write beats a bad write.
On the caller side, actually surface it:
if (args.init) {
const created = await initConfigInteractive();
process.exit(created ? 0 : 1);
}
Proving It: Testing the Interactive Path in a pty
You cannot test this properly with a pipe. readline behaves differently when stdin is not a TTY, so piping only exercises one of the two paths — and the interactive path is the one your users are on.
The one-liner smoke test is what I would add to CI first:
$ printf '\n\n\n' | sarvam --init; echo "exit=$?"
init aborted — input ended before every question was answered.
Nothing written to /home/vamshi/.sarvam/config.json.
exit=1 # ← was 0 before the fix. Non-zero is the whole point.
For the interactive path, drive a pseudo-terminal. Additionally, this needs no new dependencies — it is Python’s stdlib:
#!/usr/bin/env python3
"""Send Ctrl+D at a prompt and assert the CLI exits like it means it."""
import os, pty, subprocess, time
master, slave = pty.openpty()
p = subprocess.Popen(["sarvam"], stdin=slave, stdout=slave, stderr=slave, close_fds=True)
os.close(slave)
time.sleep(1.0) # let it draw its prompt
os.write(master, b"\x04") # Ctrl+D (use b"\x03" for Ctrl+C)
time.sleep(1.0)
print("exit:", p.wait(timeout=5))
Running it against the fixed build:
$ python3 test_eof.py
exit: 0 # ← clean shutdown, farewell line printed
# before the fix this also printed 0 — but with no farewell
That distinction is the whole test. Together, the exit code and the farewell line tell you which of the two happened. This is what continuous security validation looks like at CLI scale: assert the observable behaviour, not just the status.
Quick Reference
Expected behaviour after the fix:
| Input | Exit code | Behaviour |
|---|---|---|
exit / quit |
0 | Normal shutdown |
| Ctrl+D (EOF) | 0 | Clean shutdown, farewell printed |
| Ctrl+C (SIGINT) | 130 | Clean shutdown, distinguishable from success |
| Piped stdin, too few lines | 1 | Aborts, writes nothing |
| Approval prompt, stdin closed | — | Returns false — action declined |
Use 130 for SIGINT. That is the 128 + signal convention, and the only way a wrapping script can tell “the user interrupted this” from “this finished.” However, it needs an explicit handler, because readline’s default is a silent close:
let interrupted = false;
rl.on("SIGINT", () => {
interrupted = true;
rl.close();
});
// …after the loop:
if (interrupted) process.exitCode = 130;
Beyond Node: Any Callback With a Path That Never Runs
The specific API is Node’s. However, the pattern is everywhere: an async primitive whose completion callback has a path that never runs.
Any time you wrap a callback API in a promise, ask the same question — what are all the ways this callback might not be called? Closed streams, cancelled requests, timed-out sockets, aborted signals. In every one of those cases, a bare new Promise(resolve => api(cb)) becomes a permanent hang. Moreover, in an event-loop runtime, a permanent hang looks exactly like a clean exit.
The tell is a process that ends without printing whatever it normally prints on the way out. If your CLI has a farewell line, a summary, or a flush, its absence is your signal — not the exit code, which is lying.
CISSP Domain Mapping
| Domain | Name | Relevance |
|---|---|---|
| 3 | Security Architecture and Engineering | Secure defaults and fail-closed design. When the system loses the ability to obtain consent, it must assume consent was refused. Note how narrowly it was avoided: === "y" fails closed, !== "n" fails open, and code review rarely catches the difference. |
| 8 | Software Development Security | Error handling at trust boundaries. Silent failure is the anti-pattern — a system that cannot distinguish “succeeded” from “never ran” cannot be reasoned about, and every consumer downstream inherits the ambiguity. |
| 7 | Security Operations | Exit codes are an operational interface. 0 means a shell && chain proceeds. Returning 0 from a function that did nothing is, in automation terms, a false negative on an integrity check. |
Key Takeaways
rl.question()never fires if the interface closes first. Ctrl+D, Ctrl+C, and exhausted piped stdin all close it.- A pending promise is not a running task. Node exits cleanly when the loop empties, so the failure presents as success.
- Resolve to a sentinel, don’t reject. End of input is normal, not exceptional.
- Decide what “input ended” means per call site. Exit at a prompt, decline at a consent gate, abort at a wizard.
- Never assume consent from absent input. Write
=== "y", never!== "n". - A partial write can be worse than no write — especially where an empty string is a meaningful, shadowing value.
- Test the interactive path in a pty. A pipe tests the other code path entirely.
- Reproduce before you fix. My confident first diagnosis was wrong, and only a reproduction attempt caught it before it became a wasted refactor.
Try sarvam-cli
The CLI in this post is sarvam-cli — an MIT-licensed, open-source agentic coding assistant powered by Sarvam AI. It reads, writes, and edits files and runs shell commands in your project, with your approval before any side effect. That approval gate is exactly the one discussed above, which is why the fail-closed behaviour mattered enough to write up.
git clone https://github.com/indic-ai-contribs/sarvam-cli.git
cd sarvam-cli
npm install
npm run build
npm link
sarvam --init # exits non-zero now if you don't finish the wizard
The fixes described here shipped in v0.2.9 and v0.2.10. Issues and pull requests are welcome — particularly from anyone who has fought the same class of bug in their own CLI. If the project is useful to you, a star on the sarvam-cli GitHub repo genuinely helps it reach more Indian-language AI developers.
Get the next deep-dive in your inbox when it publishes → subscribe to linuxcent.com
