[HengyuLi-Ozaki-lab]

The second of the three pieces split out of #226, as asked there on 2026-10-13: the MCP stdio isolation for eq_mcp, tr_mcp and tot_mcp, installed from the launcher.

What

Each of the three servers gets _install_fd_isolation(): it dups fd 1 (the JSON-RPC pipe to the client), points fd 1 at stderr and rebuilds sys.stdout on the saved fd, so the library's WRITE(6,...) goes to the server's stderr and JSON-RPC keeps the pipe. main() calls it once, after the --help and --print-tools paths and the check for the MCP SDK, immediately before the stdio server is built and started. The function is idempotent. It is the form #232 gives fp_mcp.

Importing a server installs nothing and leaves fd 1 and sys.stdout alone (#227 item 1). On develop none of these servers has any isolation, so this adds it in its final place rather than moving it.

tot_mcp gets its own installer: it imports its siblings for their parameter registries, and an isolation that only tr_mcp's main() installs never runs in a tot_mcp process (the observation on #227).

Measured

One real stdio session per server (initialize, init, run; mcp 1.27.1), stdout lines that are not JSON-RPC of all stdout lines:

	develop (a0b58408)	this branch
tr_mcp	9 of 12	0 of 3
tot_mcp	9 of 12	0 of 3
eq_mcp, run(mode=1)	2 of 5	0 of 3

(eq_mcp's run(mode=1) with the defaults returns an error after EQ has printed; run(mode=0) prints nothing in either tree.)

Tests

python/mcp-servers/eq_mcp/tests/test_import_isolation.py, 19 cases over the three servers, each in a fresh interpreter: an import leaves fd 1 and sys.stdout alone; main() installs the isolation before the server is built and before its first write; a second call keeps sys.stdout on the pipe; --help, --print-tools and a missing SDK install nothing; tot_mcp's main() leaves tr_mcp uninstalled. All 19 fail on develop: seven for what develop lacks, twelve (the import, --help / --print-tools and missing-SDK cases) only because the flag they read does not exist there. Against this branch, installing at import fails 15 of them, and installing after build_server() fails the main() case of that server. The tests set PYTHONPATH for their subprocesses themselves and need neither the SDK nor a built library.

python/ with CI's flags, macOS arm64, gfortran 15: 792 passed, 35 skipped, 1 xfailed (develop: 773 passed). The 35 skips are the 19 Linux-only equivalence tests, 13 that need the mono image or TOTLIB_PATH, and 3 without a ti fixture; with the mono image, the three test_mono_* files and the three servers' tests: 173 passed.

Not in this pull request

• fp_mcp: fix(fp_mcp): redirect Fortran WRITE(6,...) to stderr to protect JSON-RPC channel #232.
• ti_mcp, wr_mcp, wrx_mcp: no isolation either (4 of 7, 5 of 8 and 0 of 3 lines not JSON in the same kind of session, measured on 2026-10-03).
• Reconcile bpsi/develop base into develop (bpsi↔fork merge baseline, CI-green) #226's _redirect_fortran_stdout_to_stderr context manager for a caller that imports a server without running main(): it stays with Reconcile bpsi/develop base into develop (bpsi↔fork merge baseline, CI-green) #226. (The Windows handling of stdin exists downstream only, not on Reconcile bpsi/develop base into develop (bpsi↔fork merge baseline, CI-green) #226.)
• tr_mcp's finalize (PR #226 follow-up: fix MCP stdio isolation, TR lifecycle, and EQ save error reporting #227 item 2): not in your list of three, so it stays with Reconcile bpsi/develop base into develop (bpsi↔fork merge baseline, CI-green) #226 too.

Scope

Based on develop (a0b58408). Python only. It shares eq_mcp/server.py with the companion pull request for eq_save (#256), in different hunks (the two merge without a conflict), and eq_mcp/server.py and tr_mcp/server.py with #226, which will take develop's version of this code when it is brought up to date.

🤖 Generated with Claude Code

[k-yoshimi]

Review of 0214201 (in-house + two independent Codex passes, plus a local run; details at the end). The mechanism is right for the normal layout: the installed mcp SDK (1.27.0) writes through TextIOWrapper(sys.stdout.buffer) and flushes after every message, so the rebuilt sys.stdout works; libgfortran keeps the fd number for unit 6, so the redirect takes effect whether or not unit 6 was used before main(); no existing in-process test reaches the install (the --help/--print-tools calls return first); the main() placement is what #227 item 1 asked for. One thing before merge, then suggestions.

Before merge

Two descriptor layouts silently defeat the isolation while _FD_ISOLATION_INSTALLED reports success (eq_mcp/server.py:90-92, tr_mcp/server.py:80-82, tot_mcp/server.py:93-95). Reproduced with a stub server that writes JSONRPC through sys.stdout and FORTRAN through os.write(1, …):

-- launched with stderr merged into stdout (2>&1): pipe got ['JSONRPC', 'FORTRAN']
-- launched with fd 2 closed:                      rc 0, pipe got ['JSONRPC', 'FORTRAN']

With fd 2 closed, os.dup(1) returns the lowest free descriptor, which is 2, so dup2(2, 1) copies the pipe onto itself. With 2>&1, fd 1 and fd 2 are the same open file description and dup2 is a no-op. Neither is a regression against develop, and MCP hosts normally give the server its own stderr, but the helper should not claim success there. Suggested shape:

• before the dup: try: os.fstat(2) except OSError: os.dup2(os.open(os.devnull, os.O_WRONLY), 2);
• then compare os.fstat(1) and os.fstat(2) (st_dev, st_ino): if they are the same file, point fd 1 at os.devnull (or a log file) instead of fd 2, and write one warning line to stderr;
• two subprocess tests: stderr=subprocess.STDOUT, and preexec_fn=lambda: os.close(2) (or pass_fds/close_fds equivalent), both asserting that the Fortran marker never reaches the pipe. Every case in test_import_isolation.py uses capture_output=True, which always supplies distinct open pipes, so these two layouts are untested today.

Suggestions (not blocking)

• One shared helper and one process-wide flag. The function is copied verbatim into three servers, and #232 makes four. python/mcp-servers/__init__.py is not an importable package (hyphenated directory), but every server already puts <repo>/python and <repo>/python/mcp-servers on sys.path, so a flat python/mcp-servers/_fd_isolation.py (or a module next to trlib) works with no packaging change. A shared flag also closes a hole the per-module flags leave: if two servers' installers run in one process (tot + tr, say), the second dup(1) saves the already-redirected stderr as "the pipe". test_installing_twice_keeps_sys_stdout_on_the_pipe covers same-module repeats only. ti_mcp, wr_mcp and wrx_mcp have the same exposure and would then adopt it in one line each. Fine as a follow-up if you prefer to keep this PR to the three servers; I will track it.
• Ordering with #232. tot_mcp imports fp_mcp.server at import time. If #232 merges in its current import-time form, test_import_leaves_fd1_and_sys_stdout_alone[tot_mcp] here goes red. So: this PR first, then #232 rebased to install from main() (ideally via the shared helper).
• Comment wording (eq_mcp/server.py:67-69 and the two siblings, same sentence in the docstrings): the SDK does not write through sys.stdout's line buffering; it wraps sys.stdout.buffer in its own TextIOWrapper and flushes explicitly. buffering=1 only affects Python-side print(). Relatedly, _STUB_SERVER writes via sys.stdout.write; one extra sys.stdout.buffer.write(b"…") would exercise the attribute the SDK actually needs.
• Import layout: import os as _os; import sys as _sys + a function above the regular import os / import sys block; in tot_mcp that gives import os as _os directly followed by import os # noqa: F401. Goes away with the shared helper.
• The test file parametrises over tr/tot but lives in eq_mcp/tests/, so pytest python/mcp-servers/tr_mcp alone never runs the tr/tot cases (CI's pytest python/ does). _run replaces PYTHONPATH rather than prepending to the inherited value.

Verified OK

• mcp/server/stdio.py (1.27.0): anyio.wrap_file(TextIOWrapper(sys.stdout.buffer, encoding="utf-8")), await stdout.write(json + "\n"); await stdout.flush(); FastMCP logging goes to a stderr console.
• A tiny WRITE(6,…) .so loaded via ctypes and called before and after the redirect in a piped subprocess: first call on the pipe, second on stderr.
• tr_mcp/tests/test_server.py:335, eq_mcp/tests/test_server.py:423,439, tot_mcp/tests/test_server.py:550,566 call main() only with --help / --print-tools.
• Local: pytest python/mcp-servers/eq_mcp/tests/test_import_isolation.py python/mcp-servers/eq_mcp/tests/test_server.py python/mcp-servers/tr_mcp/tests python/mcp-servers/tot_mcp/tests --forked --timeout=120 --timeout-method=signal on develop + this branch → 147 passed, 12 skipped (macOS, py3.10).

[HengyuLi-Ozaki-lab]

The two layouts are closed and the helper is one module: one commit on 02142011, 93779004.

Before merge. Reproduced on the three servers as you describe (stderr merged into stdout: the pipe gets both markers; fd 2 closed: the pipe gets both), and fixed in the shape you gave. Where it goes further than the shape:

• fd 2 closed. fd 2 is opened on the null device before the dup, made inheritable (when os.open itself returns 2 the descriptor is close-on-exec, and a child process would start without it), and sys.stderr, which Python leaves at None in that case, is built on it: otherwise print(..., file=sys.stderr) and a traceback are written to sys.stdout, the pipe. A repair that fails half-way is taken back, so that a second call does not find fd 2 open and skip the rest; and a sys.stderr of None beside an fd 2 that is open is given fd 2 for the same reason.
• The same file. fd 1 goes to the null device and one warning line goes to stderr. One terminal on both counts as the same file: a host that runs the server on a pty parses that stream, and a server started by hand shows the warning instead of the library's output.
• No identity. An inode number of 0 is not taken for an identity. Windows gives st_dev = st_ino = 0 for a pipe and a console (by reading CPython's source; nothing was run on Windows), and two TCP sockets gave it on macOS: comparing them would discard the library's output of every server there. So on such descriptors a merged stream is not recognised and fd 1 goes to fd 2, as before this commit.
• The saved pipe is always a descriptor above 2: with fd 0 closed as well, dup(1) returns 0.
• Nothing is changed until everything is prepared. The one call that changes fd 1 is the dup2; a failure up to and including it leaves fd 1, sys.stdout and the flag as they were and closes what was opened for the redirect (a repair of fd 2 that was completed stays), and nothing after it can fail. The old sys.stdout is flushed first and a reference to it is kept (a stream that owns fd 1 would close the redirected descriptor when collected).

Both of your tests are there, through each server's main(): stderr=subprocess.STDOUT, and preexec_fn=lambda: os.close(2).

In a real stdio session of tr_mcp (initialize, init, run) with stderr merged into stdout, the stream now carries the three JSON-RPC answers, the warning and four lines of the SDK's own log; on develop (a0b58408, no isolation) it carried 13 lines that were not JSON-RPC, nine of them Fortran output. With its own stderr and with fd 2 closed: three lines, all JSON-RPC, for each of the three servers.

Suggestions.

• One helper, one flag: taken, at python/_fd_isolation.py, beside _runtime_mode.py, and not in python/mcp-servers/. The servers put only <repo>/python on sys.path (_PYTHON_ROOT, for the library wrapper); python/mcp-servers is on the path only when the launcher's PYTHONPATH names it. A first version with the module in python/mcp-servers/ could not be imported by a server package copied out of the tree and run with PYTHONPATH=<repo>/python, and changed which copy of its siblings tot_mcp finds. Where the wrapper is found, the module is found. Two servers' main() in one process is a test (tot, then tr: both answers on the pipe, both Fortran lines on stderr).
• Ordering with fix(fp_mcp): redirect Fortran WRITE(6,...) to stderr to protect JSON-RPC channel #232. fix(fp_mcp): redirect Fortran WRITE(6,...) to stderr to protect JSON-RPC channel #232 has installed from main() since cd51cb4d (pushed 2026-10-13), so test_import_leaves_fd1_and_sys_stdout_alone[tot_mcp] stays green in either order. Once this is in develop I will change fp_mcp in fix(fp_mcp): redirect Fortran WRITE(6,...) to stderr to protect JSON-RPC channel #232 to the shared module (an import and the call). ti_mcp, wr_mcp and wrx_mcp are not in this pull request; each needs the same two lines.
• Comment wording: corrected in the module's docstring (the SDK wraps sys.stdout.buffer and flushes itself; the line buffering only matters for print()). The stub server writes through sys.stdout.buffer.
• Import layout: gone with the copies. Each server now differs from develop by an import after the wrapper's and one call in main().
• Where the tests live. python/mcp-servers/fd_isolation_cases.py holds the cases every server has to pass, and each server's tests/test_fd_isolation.py runs them for itself (7 each), so pytest python/mcp-servers/tr_mcp includes tr's share. python/tests/test_fd_isolation.py has the module's own cases (17), three of which check that each server's file calls every shared case. The child's PYTHONPATH is prepended to. eq_mcp/tests/test_import_isolation.py is removed; its cases are among these.

Measured. 38 cases against 19. Each of these changes to the module makes at least one case fail (the number that fail): no flag (2), fd 2 not repaired (8), fd 2 repaired with the pipe (6), a merged stream not recognised (5), identity 0 accepted (1), the old stream not kept (1), sys.stderr not repaired (4), fd 2 left close-on-exec (1), the old stdout not flushed (1), the pipe saved on the lowest free descriptor (1), no cleanup after a failure (2), the warning not best effort (1), a failed repair of fd 2 not undone (1), sys.stderr built only on a descriptor the call opened (2), the repaired sys.stderr strict and block-buffered (1), the null device left open (1), the undo closing an fd 2 it did not open (1), the repaired sys.stderr owning fd 2 (1). One detail has no case: closefd=False on the new sys.stdout. The cases also pass with PYTHONDEVMODE=1, PYTHONWARNINGS=default and PYTHONUNBUFFERED=1. On macOS the suite is 811 passed, 35 skipped, 1 xfailed with the CI flags.

Not run: Windows, and Linux before this push.

[k-yoshimi]

Re-review of 9377900 (in-house + Codex on the delta; locally in a scratch worktree: pytest python/tests/test_fd_isolation.py python/mcp-servers/{eq,tr,tot}_mcp/tests --forked --timeout=120 --timeout-method=signal → 166 passed, 12 skipped; my own two probes against the new code: with 2>&1 the pipe carries the warning line and the JSON-RPC marker and the Fortran marker is discarded, with fd 2 closed the pipe carries the JSON-RPC marker only).

Verified: fd 2 closed → /dev/null on 2 (direct or via dup2), inheritable, sys.stderr rebuilt; fd 0 and 2 both closed → fd 0 stays closed and the saved pipe is 3; the (st_dev, st_ino) identity with the st_ino != 0 guard works on macOS (pipes have st_dev 0 but unique inodes) and Linux, and on Windows falls through to the plain dup2(2, 1) as documented; failure paths undo what they opened and leave fd 1 / sys.stdout / the flag untouched; the SDK's TextIOWrapper(sys.stdout.buffer) is built at run time and finds the rebuilt stream; libgfortran's unit 6 follows fd number 1. The three servers differ from develop by one import and one call in main() after the --help / --print-tools / SDK-missing returns; no stale names remain. #232's cd51cb4d does install from main(), so the order no longer matters; whichever lands second rebases its main().

Approving. Notes, none blocking:

• A server started by hand in a terminal has fd 1 and 2 on the same pty, so it is now classified "same file" and the library's output is discarded (the CHANGELOG says so). A one-line os.isatty(1) exemption would keep manual runs useful for debugging; fine as a follow-up.
• Windows: the merged-stream case is not detected there (documented), so Windows keeps develop's behaviour; nothing was run on Windows, which #240 will have to cover.
• Nits: _repair_fd2 treats every fstat(2) OSError as EBADF (checking errno would be stricter); previous.flush() catches OSError / ValueError only; the merged layout puts the warning line itself on the JSON-RPC stream before the first message (deliberate, the host put stderr there).
• fp / ti / wr / wrx servers still write Fortran output to their pipes (fp via #232; the other three are the same two lines each).