mcp-stdio-fail-closed c3: the stdio MCP transport starts but is permanently deaf (oclif arg parser pauses process.stdin)

[huangyiirene]

The fail-closed contract this item exists to pin (clauses 0–2, 7) PASSES and is correct — please do not "fix" it: stdio enabled with no key throws at plugin start and the kernel rolls back with the port closed; an unknown/revoked key draws the same refusal with no anonymous-but-serving fallback; a real member key binds the principal to that member (not admin); and stdio off boots cleanly with an explanatory line while HTTP is still served. The defect below is only that the started transport never answers.

Symptom

With the stdio transport successfully started ([MCP] Server started (transport: stdio) logged), the transport never answers a single JSON-RPC request.

• Observed: initialize, tools/list, resources/list, resources/read all time out with zero bytes on stdout, across 4 separate runs. Malformed input draws no error either. Clause 3 fails; clauses 4–6 are blocked as a consequence.
• Expected: a started, principal-bound stdio transport answers initialize (and the rest) over the child's stdin/stdout.

An instrumented probe 40 s after boot reports listeners(data)=1 readableFlowing=false isPaused=true bytesRead=0 — the data listener is attached, but process.stdin is paused.

Root cause

oclif's argument parser opens a readline Interface over process.stdin and closes it on its abort signal; Interface.close() calls stdin.pause(). Captured stack:

at Interface.pause (node:internal/readline/interface:539)
at Interface.close (node:internal/readline/interface:525)
at signal.addEventListener.once (@oclif/core/lib/parser/parse.js:64)

So the deafness is in the host process, above the plugin. Two controls isolate it there: (a) a bare @modelcontextprotocol/sdk McpServer + StdioServerTransport answers the identical bytes, and (b) ObjectStack's own MCPServerRuntime({transport:'stdio'}) answers too — both in a plain node process. MCPServerRuntime.start() (packages/mcp/src/mcp-server-runtime.ts:807-811) simply constructs new StdioServerTransport() and connect()s it; nothing resumes process.stdin after oclif's parser has paused it. On origin/main the connect region carries no stdin.resume() mitigation.

Consequence: every objectstack serve/dev stdio transport is started-but-deaf — OS_MCP_STDIO_ENABLED=true advertises and logs a principal-bound stdio server that no MCP client can ever talk to. The 17/17 unit pins are green because the gap is above the plugin.

Reproduction

1. Spawn node packages/cli/bin/run.js serve -p <port> --dev with stdio:['pipe','pipe','pipe'], OS_MCP_STDIO_ENABLED=true, and a valid osk_ key.
2. Wait for [MCP] Server started (transport: stdio).
3. Write a JSON-RPC initialize line to the child's stdin.

Expected an initialize result. Actual nothing, ever (zero bytes on stdout).

Source

Extracted from the QA run #7627 (framework 92f26f7, console 6314e87f).

[hotlong]

Claim: PM loop round 2 — domain:cli seat.

• Session: session_01B3Kurx8qufrDzNjk4rag7V (account hotlong)
• Branch: claude/issue-7645-mcp-stdio-deaf
• Worktree: objectstack-issue-7645
• Domain: domain:cli
• File surface: packages/mcp/src/mcp-server-runtime.ts (the start() / StdioServerTransport connect region, ~:807-811), and the CLI serve/dev host path only if the measurement proves the resume must live there (packages/cli/src/commands/). Stop on breach; explain in the report.
• Container & model: M, mode:subagent (cloud dispatch unavailable this session — sanctioned fallback), model: opus.
• Serial constraints cleared: no in-flight cli claim touches packages/mcp or the CLI serve host. finding: /meta/_drafts serves DRAFT object schemas unmasked — the one ADR-0106 outlet left uncovered #6599 is in rest-server.ts (_drafts region) + runtime/domains/meta.ts; [finding] ctx.log.debug is inferred, granted and documented, but the sandbox never installs it — a body calling it throws TypeError: not a function #7661 is in runtime/src/sandbox/**; [finding] packages.ts:337 promises a wire-field rename that the objectui follow-up measured out — the comment is now a false pointer #7578 is runtime/src/domains/packages.ts. All disjoint from this surface.

What is and is not in scope

⛔ The fail-closed contract (clauses 0–2, 7) PASSES and must not be "fixed" — the card is explicit. Startup refusal with no key, refusal on unknown/revoked key with no anonymous fallback, member-key principal binding, and clean boot with stdio off are all correct today. A diff that changes any of those is a regression, not a fix.

The defect is exactly one thing: a started stdio transport never answers because oclif's arg parser opens a readline Interface over process.stdin and its abort handler calls Interface.close() → stdin.pause(). The transport's data listener is attached; the stream is paused. Clause 3 fails, 4–6 are blocked behind it.

The interesting question the dispatch wants answered, not assumed: the pause happens in the host (above the plugin), so "where does the fix belong" is a real call — resume at the point of connect() in mcp-server-runtime.ts, or stop the host from pausing a stdin that a transport owns. The dev is instructed to state which and why, and to say plainly if the chosen seam leaves the other one still able to re-break it.

Pin the consequence, not the mechanism. A test asserting isPaused() === false would pass over a transport that still answers nothing. The pin must be that a spawned CLI process with stdio enabled answers a real initialize over its stdin/stdout — the card's own repro is the acceptance criterion, and the 17/17 existing unit pins are green precisely because they sit below the gap.

---

Generated by Claude Code

[hotlong]

Dispatch-mode correction to the claim above: mode:subagent → mode:cloud.

Cloud dispatch was unavailable when I wrote the claim and became available minutes later, so this M card is dispatched the way #7341 requires (M and above default to a dedicated cloud container) rather than the shared-container fallback.

• Cloud session: session_01Qxkv33VVJAYJptjGmjTzFG
• Title: cli #7645 stdio MCP transport is started-but-deaf
• Model: claude-opus-5, outcome_branch: claude/issue-7645-mcp-stdio-deaf

Everything else in the claim stands unchanged — file surface, the ⛔ do-not-"fix"-the-fail-closed-clauses boundary, and the consequence-level pin (a spawned CLI process must answer a real initialize, not merely report an unpaused stdin).

---

Generated by Claude Code