Run on host, access from sbx?

[jfahrenkrug]

Hi,
I usually use sbx to safely run my agents in YOLO mode. Of course sbx spawns a Linux microVM, so it can't access my Mac applications (like Xcode).
I was wondering: Is it possible to run XcodeBuildMCP on the host (macOS), and then run my agent inside sbx and have it "call out" to the MCP server running on the host using HTTP? Has anyone tried that?

• Johannes

[ECD5A]

The host/guest architecture is possible, but XcodeBuildMCP does not currently expose an HTTP transport itself. The current server constructs StdioServerTransport, and xcodebuildmcp mcp starts that stdio server, so there is no native --http or --port mode to point sbx at.

The simplest bridge is usually stdio over SSH, which avoids adding an HTTP proxy. Configure the MCP command inside the sbx guest as the equivalent of:

{
  "command": "ssh",
  "args": [
    "-T",
    "mac-builder",
    "/absolute/path/to/xcodebuildmcp",
    "mcp"
  ]
}

The MCP client still sees a normal local stdio process (ssh), while the actual XcodeBuildMCP process and all Xcode operations run on macOS. Use -T so no pseudo-terminal alters the JSON-RPC stream, a dedicated SSH key, and an absolute executable path because non-interactive SSH shells often have a different PATH.

A stdio-to-Streamable-HTTP proxy on the Mac is another option, but it is an extra component rather than a built-in XcodeBuildMCP feature. If you use one, bind it only to an interface reachable from the microVM, require authentication/TLS, and do not expose the raw endpoint publicly. sbx must also allow outbound access to that host address; guest localhost is the guest, not macOS.

Two operational details matter whichever bridge you choose:

• project/workspace paths passed to tools are paths on the Mac host, so the source must be present there (or mounted/synchronized there);
• session defaults and stateful operations are easier to reason about with one server process per agent/session rather than several agents sharing one long-lived process.

So: yes, the split is viable, but today it needs SSH-stdio or a transport proxy; direct HTTP is not supported by XcodeBuildMCP itself.

[gergomiklos]

If keeping the agent off your own Mac is the reason for sbx, there's one more variation of the SSH bridge above: point it at a throwaway cloud Mac instead of the host. Xcode then runs somewhere the agent can't hurt, and your machine stays out of it entirely.

Disclosure: I built NoMac, which is one of those (a macOS VM per session, deleted when it stops). Inside the sbx guest, install @nomac/cli, run nomac start and nomac ssh-config (which names the Mac nomac in your SSH config), and the MCP command becomes:

{
  "command": "ssh",
  "args": ["-T", "nomac", "npx", "-y", "mobilebuildmcp@latest", "mcp"]
}

The guest needs outbound HTTPS to nomac.app. And the same caveat as with the host applies: the server works on the Mac's copy of the project, so sync it first (nomac sync .).