`confirm()` has no TTY check — an agent that omits `-y` hangs forever

[KalebCole]

confirm() at src/lib/events.ts:26-35 reads from stdin via readline. It is used by three mutating commands:

• src/commands/rsvp.ts:153
• src/commands/blasts.ts:84 (send blast)
• src/commands/events.ts:580 (cancel event)

Each is correctly gated by if (!globalOpts['yes'] && !globalOpts['force']), but there is no process.stdin.isTTY check. In a non-interactive context the readline promise never resolves, so the process hangs indefinitely rather than failing.

AGENTS.md already documents this as a known trap: "events cancel and blasts send prompt for confirmation before executing. Pass -y or --yes to skip in automated/agent flows." An agent that misses that line doesn't get an error it can recover from — it gets a hang, which is much harder to diagnose and can silently consume a whole session.

src/commands/auth.ts:167 (SMS code prompt) has the same shape.

Fix

Fail closed. When process.stdin.isTTY is falsy and neither --yes nor --force was passed:

• exit with EXIT.VALIDATION_ERROR (3)
• emit the standard error envelope with an actionable hint, e.g. "pass -y/--yes to confirm in non-interactive contexts"

Never auto-approve on a non-TTY — these are destructive operations (cancel event, send blast to all guests).

This is probably the single highest-value agent-reliability fix in the repo: it converts a silent hang into a typed, self-explaining error.

[forevercrab321-svg]

Fail-closed on !isTTY is right. The part I would separate out is the verification, because that is the piece that does not exist yet.

Four call sites are named here — the three mutating commands plus auth.ts:167. The class is "an operation that neither completes nor errors," and nothing in the repo currently distinguishes a hang from a slow run. So the fifth blocking read that gets added next month has the same shape and produces the same non-signal, and this fix stays checkable only by reading the diff.

Ours, this week. Our platform watch reported that the request logs carried no IP and no user-agent. They were there the whole time, in a different table — the query shape we were using returns a 500 on that endpoint. A broken read and an empty world printed identically, and we believed the empty one for a full round before anyone re-checked.

Free half, and it is one test rather than four: spawn the built CLI with stdin closed against each mutating command without -y, and assert a non-zero exit within a couple of seconds. That binds the whole class instead of the enumerated sites, and it goes red today — before the fix — which is the only way to know the test can fail at all.

So the question that decides whether the fix is verifiable: does anything in the suite currently invoke the CLI with stdin closed, or is every existing invocation running under a TTY?