QNX Host MCP

MCP server over stdio for inspecting a configured QNX compiler and compiling workspace C sources with fixed arguments. Operations return an ID for status polling and cancellation.

Real compilation and execution of the unchanged artifact inside QNX 8.0.0 x86_64 in QEMU 8.2.2 were completed on the project host. Guest execution evidence records the expected message and exit status 0.

Configuration

Requires Node.js 22 or later and the existing project dependencies. Configure an absolute QNX_MCP_WORKSPACE directory containing src/hello.c and a trusted PATH containing the QNX executables. The server resolves executables from absolute PATH entries and invokes them without a shell. It forwards selected host and QNX environment variables only.

Example Claude Code configuration:

{
  "mcpServers": {
    "qnx-host": {
      "command": "node",
      "args": ["/absolute/path/qnx-mcp/src/server.mjs"],
      "env": {
        "QNX_MCP_WORKSPACE": "/absolute/path/qnx-workspace",
        "PATH": "/absolute/path/to/qnx/compiler/bin:/usr/bin:/bin"
      }
    }
  }
}

The project environment uses QNX SDP 8.0 on Ubuntu 24.04 under WSL2. Compiler evidence identifies GCC 12.2.0 and the QNX x86_64 target. SDK installation and licensing were not audited by this documentation update.

Related MCP server: Delphi Compiler MCP Server

Compilation smoke and evidence

Run from the repository root after loading the licensed SDK environment:

npm run smoke

For validation without the SDK:

npm run smoke:fake

The smoke uses the installed MCP Client and StdioClientTransport to launch src/server.mjs, list tools, inspect the compiler, compile examples/hello/src/hello.c and poll operation status with bounded waits. It writes report.json and report.md under evidence/-/. Use --evidence-root DIRECTORY to select another report destination.

Reports include compiler version and target output, operation exit codes, reconstructed compiler arguments, artifact size and SHA-256. Arguments come from the fixed executor contract, not a server-provided execution trace. The smoke independently verifies artifact size and hash. Fake mode additionally checks arguments recorded by the simulated compiler.

Fake reports identify simulated evidence and do not demonstrate QNX compatibility. Real mode uses the operator's PATH; inspect compiler output alongside environment details. The compilation smoke does not execute artifacts or call image tools.

Retained real compilation — 2026-11-03

Evidence: report.json, report.md and host-facts.txt. JSON and Markdown describe one run.

The report represents the source as /path/to/qnx-mcp/examples/hello/src/hello.c and output as /path/to/qnx-mcp/examples/hello/build/0279c855d511a150ba531331739c259b/program. These are recorded project-host paths. The fixed target argument is -Vgcc_ntox86_64.

The report records independentlyVerified: true and retained: true. This documentation update inspected records without rehashing binaries or checking current retention. The output does not identify an additional SDK patch version. Exact compiled source-commit provenance remains unestablished. See REAL-QNX.md for compiler reproduction guidance.

For the separate SDK image and QEMU reproduction procedure, see Real QNX compilation and guest execution. Retained evidence files preserve original host paths; adapt working copies for a new run.

Successful QNX guest execution — 2026-11-03

Evidence: execution README, serial console and hash records. The separate SDK/QEMU workflow ran on the project host: Ubuntu 24.04 on WSL2, kernel 6.6.87.2-microsoft-standard-WSL2, QEMU 8.2.2 from the Ubuntu archive. It used TCG with -cpu max; no KVM device was available.

QNX_MCP_RUN_BEGIN
QNX noname 8.0.0 2026/06/05-16:26:03EDT x86pc x86_64
Hello from QNX MCP smoke.
QNX_MCP_RUN_EXIT=0

The unchanged 9208-byte program has the same SHA-256 recorded by the compiler smoke. sha256.txt matches the original program and automata-hello; the recorded output/ifs.bin SHA-256 is e606657ba117cbdb05ddea7385e92f5493e0b7712c82ce368fa15285be72f8fe. The execution README reports three independent compilations with the same program hash; additional compilation reports were not inspected here.

The SDK's mkqnximage --type=qemu --arch=x86_64 --graphics=no, using /root/qnx800/target/qnx, built the image. As described in the evidence README, ifs_files.custom places the unchanged artifact at /proc/boot/automata-hello; post_start.custom runs it during startup and prints its exit status. No login was performed. The retained run-qemu.sh is described as waiting for the marker and stopping QEMU with SIGTERM. This update did not run these files.

The guest had no network interface. Its unedited console reports no valid interfaces found and an sshd startup failure, Memory fault (core dumped), before the successful program output. Networking and SSH operation were not validated. The SDK image tools placed the artifact; the MCP server did not transfer it. All four MCP image lifecycle tools remain blocked with UNSAFE_CONFIGURATION.

MCP tools

• qnx_toolchain_info: fixed qcc --version and qcc -V commands; 30-second deadline.

• qnx_compile_c: accepts src/name.c, compiles for QNX x86_64 and checks build//program; 120-second deadline. Returns artifact path, size and SHA-256.

• qnx_operation_status and qnx_operation_cancel: supervise operation IDs created by this executor. Cancellation acceptance precedes confirmed termination.

• qnx_image_build, qnx_image_start, qnx_image_ip and qnx_image_stop: remain blocked with UNSAFE_CONFIGURATION.

Output is capped at 32 KiB per stream. Excess output is drained and reported as OUTPUT_LIMIT. Process cancellation targets the operation's Linux process group and escalates after the configured grace period. Native Windows process execution remains disabled.

Image configuration

QNX_MCP_IMAGE_CONFIG optionally names an absolute operator-controlled JSON file containing exactly:

{
  "version": 1,
  "enabled": false
}

Absent configuration defaults to disabled. Invalid configuration prevents startup. enabled=true does not activate the MCP image tools. The separate SDK/QEMU execution evidence does not change this gate.

Internal image lifecycle

Executor.imageOperation(action, imageName) is an internal interface for direct tests; the MCP dispatcher does not invoke it. Actions are build, start, ip and stop. Names contain 1–32 lowercase ASCII letters, digits or hyphens. Image directories reside under workspace/images/.

Commands use fixed arguments: --type=qemu --arch=x86_64 followed by --build, --run, --getip or --stop. Deadlines are respectively 900, 60, 20 and 30 seconds. An internal image operation starts only when no operation is active. Images must have been built by the same executor before start; IP lookup and stop require a recorded instance.

Internal startup retains a persistent launcher, reads output/qemu.pid and checks captured Linux process identities and ancestry. Socket observation uses Linux procfs unless a test observer is injected. The unsafeListeningPorts function checks owned TCP listeners against exact 127.0.0.1 and ::1. This point-in-time observation does not establish network isolation or guest readiness.

Stop checks ownership before invoking the fixed --stop command. Cleanup observes removal of the captured target and launcher and may fall back to signalling the captured launcher group after identity checks. Unconfirmed cleanup returns CANCEL_FAILED. Controlled-process tests and the separate SDK/QEMU guest run do not establish the real mkqnximage ownership and stop behavior of this internal executor.

See Image notes, Launcher validation and Demo plan. All four MCP image tools remain blocked pending verified host controls.

Tests

npm test

Reported results on the project host comprise six consecutive complete WSL runs, each passing 60/60, and an integrated-project run passing 60/60. Their underlying suite logs were not inspected for this update. Separately, the isolated Linux candidate previously produced an observed result of 60 passed, zero failed, zero cancelled and zero skipped.

Regression tests use fake executables, controlled Linux processes and supplied socket tables. Guest execution is supported by the separate retained console evidence, rather than those regression tests. No tests were repeated for this documentation update. The CI workflow specifies Ubuntu and Node 22; execution on GitHub remains unverified.

Scope and limitations

Real compilation and subsequent guest execution are supported by separate retained evidence. The compilation smoke does not run artifacts. The SDK/QEMU workflow records QNX 8.0.0 x86_64, expected program output and exit status 0. It does not establish networking, SSH, MCP image lifecycle operation or host isolation. The guest had no network interface and sshd startup failed with a memory fault. No login was performed.

Canonical path checks do not provide operating-system isolation. Persisted image configuration, actual stop scope, descendant ownership and live networking require verification before enabling MCP image execution. Use trusted source files and an operator-controlled workspace.

The retained evidence was produced from a working copy of this source before publication; the exact source revision it was compiled from is not recorded in the reports.

QNX Global Hackathon

This project is an entry for the QNX Global Hackathon, Developer Tooling and Host Tools category. The evidence is summarized in EVIDENCE.md and the demonstration plan is in DEMO.md. The simulated demonstration remains a labeled rehearsal.

Publication note: project and validation paths in this document use neutral placeholders. Consult the unchanged evidence files for original recorded paths.