[Bug] modelopt-mcp: all launcher subprocesses hang when the server runs as a stdio MCP server — missing stdin=DEVNULL #2551

Summary

Every tool that shells out to modelopt-launcher hangs until its internal timeout when modelopt-mcp is launched the way MCP clients launch it (stdio subprocess). The same command run manually from a shell finishes in ~2 s. One-line fix per call site: stdin=subprocess.DEVNULL.

Environment

Steps to reproduce

1. Sparse-checkout and install the server exactly as documented in tools/mcp/README.md:

   git clone --depth 1 --filter=blob:none --sparse https://github.com/NVIDIA/Model-Optimizer.git
   cd Model-Optimizer && git sparse-checkout set tools/mcp tools/launcher
   cd tools/mcp && uv sync --python 3.12

2. Start the server as a stdio subprocess (any MCP client does this; .mcp.json in plugins/modelopt/ is exactly this shape) and call:

   {"name": "submit_job",
    "arguments": {"yaml_path": "examples/smoke/nvidia_smi.yaml", "dry_run": true}}

3. Observe: returns after 60 s with

   {"ok": false, "dry_run": true, "reason": "dry_run_timeout", "exit_code": null,
    "stdout_tail": "", "stderr_tail": "",
    "diagnostic": "launch.py --dryrun did not return within 60 seconds..."}

   Note stdout_tail/stderr_tail are empty — not even the resolved-job-spec table the launcher normally prints.

4. Control — run the identical argv by hand from a shell:

   modelopt-launcher --yaml <abs>/examples/smoke/nvidia_smi.yaml --dryrun --yes

   → prints the full resolved spec and exits rc=0 in ~2.1 s.

Root cause

tools/mcp/modelopt_mcp/bridge.py spawns the launcher with capture_output=True, which redirects stdout/stderr only. stdin is left inherited. For a stdio MCP server, the inherited stdin is the MCP JSON-RPC transport pipe, so the child contends with the server for the same stdin handle and blocks.

Not specific to dry-run — all three launcher call sites are affected:

The comments at ~1454 already note that without --yes nemo_run's entrypoint blocks on a confirmation prompt "and since we're capturing stdout (no TTY), the prompt would hang until the 60-second timeout fires" — this is the same class of problem via a different handle.

Fix

subprocess.run(argv, env=child_env, capture_output=True, text=True,
               timeout=60, check=False,
               stdin=subprocess.DEVNULL)          # dry_run
# and stdin=subprocess.DEVNULL on the Popen and the 300 s run as well

Verification after the fix

stdout_tail now contains the resolved SandboxTask0 spec, i.e. the YAML loader + factory resolution actually ran.

Notes

• A standalone repro with a fresh, never-written pipe (subprocess.PIPE held by a plain parent) does not hang, so the trigger is specifically inheriting the server's live stdio pipe. Environment matrix (cwd × NEMORUN_HOME × stdin shape) was tested; only the MCP-server context reproduces it.
• verify_setup is unaffected (its subprocesses fail fast with FileNotFoundError on hosts lacking docker/slurm); list_examples is pure Python.
• Suggested test: a tests/-level regression that asserts every subprocess.* call in bridge.py passes an explicit stdin=.