Vex Studio

Vex Studio exposes Vex’s agent tool surface (balances, research, quotes, swaps, bridges, plus 140 protocol tools across 11 integrations) to the coding agent you already work in. Your editor’s agent asks Vex for on-chain work; Vex still holds the keys, and in a restricted project every mutating call still clears an approval inside the app.

Mechanically it is an MCP server that Vex hosts locally, plus a small Go binary (vex-mcp) that bridges any stdio MCP client to it, plus an installer that writes the per-project config each client expects.

The local MCP server

Vex hosts the MCP server on a unix socket on macOS and Linux. The Windows named pipe is designed and vector-tested, but the transport is refused at runtime with windows_pending_platform_proof until CI proves its security descriptor, so on Windows Studio does not connect.

The socket only listens while the app is unlocked and ready. That is deliberate: a self-custodial wallet should not leave an always-open door on the machine. Locking Vex closes the listener synchronously and destroys every registered socket in the same tick, so a bridge is told rather than left waiting.

The host is bounded rather than elastic: at most 16 established connections, 4 connections waiting to handshake, and 32 calls in flight at once. Past a bound the next connection gets a typed refusal instead of an unexplained close.

The vex-mcp bridge

Coding agents speak MCP over stdio; Vex listens on a socket. vex-mcpis the standalone Go binary that connects the two. It ships inside the packaged app (under the app’s resources/bridge/), and the configs Vex writes name that absolute path rather than a bare command, so no other binary called vex-mcp on your PATH can be spawned in its place.

It is deliberately dumb: it reads nothing but its own flags and environment, does no retries anywhere, prints one sentence to stderr when something is wrong, and exits with 0 on success and one of 12 distinct codes otherwise, one per failure class. A failure is legible in your client’s log instead of hanging. The codes separate the cases that look alike from the outside:

The remaining codes cover the rest of the failure surface (bad arguments, endpoint refused, dial failed, handshake failed, incompatible protocol version, malformed frame, relay failure, signal) in the same one-line style.

Projects and the command

Studio is scoped per project: a folder under the projects root plus one backing Vex session. Each project has its own uuid, and the bridge is always told which one it is serving, either as an argument or through the VEX_PROJECT_ID environment variable:

vex-mcp --project <uuid>

# or, equivalently:
VEX_PROJECT_ID=<uuid> vex-mcp

You don’t have to assemble this by hand. The installer writes it into your client’s config file, with the absolute bridge path and the project’s uuid already filled in, under the server key vex. See Supported agents.

Studio projects live in a user-visible workspace, deliberately outside Vex’s config directory: by default ~/Vex/projects. You can point that somewhere else with projectsRoot in config.json, absolute paths only. The root is anchored in the database at first project creation and proved unchanged on every read and write, so moving it once projects exist is refused rather than silently re-homing them. See Configuration and Environment variables.

What carries over, and what doesn’t.

Studio exports the agent tool surface, but not the parts that only make sense inside a Vex session: memory, missions and the session-bound primitives stay in the app, and ToolSearch exports read-only as vex_ToolSearch. Protocol tools are callable directly by name over MCP, with no activation step. Mutating calls from an external agent route through Vex’s own approval broker, with an approval window of 1 hour. The full list is on Studio approvals & scope.