displayDialogLine

displayDialogLine(message, tone?): void

Defined in: packages/core/src/utils/consoleUtils.ts:252

Print one line of an interactive dialog — an approval prompt, an attack banner — on stderr.

One dialog, one stream

A dialog’s meaning is carried by the ORDER of its lines: a heading, then whose words the next lines are, then the words. Two streams cannot promise an order. Only writes to the same stream are delivered in the order they were made — across stdout and stderr nothing is promised, and the difference is observable the moment the two go to different places: with stdout a pipe or a file it is block-buffered while stderr is not, so a captured run can carry a rater’s answer above the command it answers. A security dialog whose line order holds only on a terminal is not a gate, so every line of one goes through here and through nothing else.

stderr, because a prompt is not program output. It is the conventional home for interaction, it is not block-buffered, and it leaves stdout carrying only what the run produced. The cost is real and is documented for users: piping stdout (gth code --no-tui | tee log) no longer captures the dialog — the terminal still shows it, 2> still collects it, and an enabled session log still records it. The log write here is UNCONDITIONAL, which the gated helpers’ is not: theirs sits behind the level guard, so a quieted console drops those lines from the transcript as well as from the screen. A dialog stays whole in both places.

Not level-gated, on purpose

The dialog is a QUESTION, not a status message, and the level filter is per line: gated, a quieted console prints the parts above its threshold and drops the rest, which is how an approval prompt comes to show a severity heading with no command under it. Half a dialog is worse than none, because it still looks like a whole one.

Parameters

message

string

tone?

DialogTone = 'plain'

Returns

void