MCP server: confirmAction can deadlock the Node event loop in non-TTY parents

[apireno]

Symptom

When the MCP server is launched without `--no-confirm` from a non-interactive parent (Claude Desktop, Cursor, any GUI MCP client), a `tier === "write"` command can deadlock the entire Node.js event loop instead of producing a clear deny.

Root cause

`confirmAction` (mcp-server/index.ts:85) attempts to read user input via:

```typescript
const fd = openSync("/dev/tty", "r+");
writeSync(fd, prompt);
const bytesRead = readSync(fd, buf, 0, 10, null); // synchronous, blocks
```

The intended fallback is a try/catch — if `openSync` fails, deny. The bug: on macOS spawned from a GUI app, `openSync("/dev/tty", "r+")` can succeed (the file exists), but `readSync` blocks waiting for input that will never arrive because there's no human at any terminal. JavaScript is single-threaded: while `readSync` blocks, the event loop is frozen. The 60s `setTimeout` fallback that follows cannot fire — the entire Node process is stuck in the syscall.

Fix (shipping in MCP server 2.0.1)

Detect non-TTY parents at module load via `process.stderr.isTTY` and skip the `/dev/tty` probe entirely. In non-TTY mode without `--no-confirm`, deny clearly with a message pointing the user at the right flag.

```typescript
const HAS_INTERACTIVE_TTY: boolean = !!(process.stderr as any)?.isTTY;

function confirmAction(description: string): Promise {
if (NO_CONFIRM) return Promise.resolve(true);
if (!HAS_INTERACTIVE_TTY) {
log(`Cannot confirm '${description}' — no interactive terminal attached.`);
log("Restart the MCP server with --no-confirm to auto-approve in non-interactive mode.");
return Promise.resolve(false);
}
// ... existing TTY logic ...
}
```

Documentation follow-up

README and `init` wizard should add `--no-confirm` to Claude Desktop / Cursor / Windsurf example configs by default — the per-action prompt is meant for users who run the server manually in a terminal, not for stdio-spawned MCP setups.

[m13v]

the per-action confirmation pattern keeps breaking at the same seam in stdio MCP servers: the server is the wrong layer to own approval. it has no UI, no conversation context, no scope info to render the decision usefully. the cleaner split is server tags tier=write in metadata, host renders 'this tool wants to do X on Y, approve?' with the surrounding context. --no-confirm becomes the right default for stdio not because confirmation is gone, but because it moved up a layer where the user can actually see what they're approving. the TTY check fixes the deadlock; the architecture question is whether confirmAction should exist at the server at all.

[apireno]

@m13v — great framing, and you're right. The default flip we shipped earlier on the release/1.3.1 branch (commit 776bf39) was the first half — stop the server from owning per-action approval in stdio setups. We were missing the second half: publish the tier metadata so hosts can do the approval at the right layer with the right context.

Just landed that in ea6fa3b — ToolAnnotations on every one of the 38 tools:

ANNO_READ      readOnlyHint: true,  openWorldHint: true
ANNO_NAVIGATE  readOnlyHint: false, destructiveHint: false, openWorldHint: true
ANNO_WRITE     readOnlyHint: false, destructiveHint: true,  openWorldHint: true
ANNO_SENSITIVE readOnlyHint: false, destructiveHint: true,  openWorldHint: true

Mapping:

• read — tabs, here, ls, cd, pwd, cat, find, grep, tree, read, text, refresh, diff, extract_links, extract_table, screenshot, wait, functions, eval → readOnlyHint: true
• navigate — navigate, open, back, forward → destructiveHint: false
• write — click, focus, type, key, scroll, select, js, close, submit, call, watch, for, each, script → destructiveHint: true
• sensitive — whoami → destructiveHint: true
• default domshell_execute — destructiveHint: true (worst-case applies)

confirmAction stays behind the opt-in --confirm flag for users running the server in their own terminal — that's still legitimate UX in that one context — but it's decisively no longer the default path. Architecture is now: server tags tier, host owns the prompt.

Thanks for the push. Shipping in @apireno/domshell@2.0.1.

[apireno]

Shipped in MCP server 2.0.1 (joint release mcp-v2.0.1, 2026-05-26).

Two-part resolution: (1) per-action terminal confirmation is OFF by default — --no-confirm is now a no-op kept for backward compat, --confirm is the new opt-in for terminal users; the underlying TTY deadlock is fixed defensively; (2) all 38 tools now carry MCP ToolAnnotations (readOnlyHint / destructiveHint / openWorldHint) so MCP hosts can render approval at the right layer with context. Thanks @m13v for the architectural framing — the second commit (ea6fa3b) was directly your suggestion.

See CHANGELOG.md for the per-bullet detail.