All docs ▾
Getting started
Using Vex
Studio approvals & scope
What is exported, what never is, and the 1-hour approval window.
Vex Studiohands an external coding agent Vex’s tool surface, but not all of it, and not with a shortcut around approvals. Two rules define the boundary: session-bound tools never leave the app, and a mutating call in a restricted project routes through the same in-app approval broker your own chat sessions use.
What gets exported
The default is generous. The export scope is written as an exclusion list, so a new tool exports unless someone records a reason it should not. The surface a coding agent sees is 167 tools: 27 internal Vex tools (wallet reads, chain reads, token checks, research, quotes, swaps, bridges, sends and the prepare/confirm pairs) plus the 140 protocol tools across 11 protocol integrations. Of those, 50 carry the MCP destructive hint. Every namespace exports.
Protocol tools are callable directly by name over MCP, with no activation step, because an MCP client’s tool list has to be the same for every project, client and environment. The list is emitted in one deterministic order for exactly that reason.
With two carve-outs: the session-bound tools below, and ToolSearch, which exports as vex_ToolSearch through its own read-only adapter. It searches the catalog and runs nothing: it never writes a session working set, its select:mode is refused by name, and a tool whose environment variable is unset is still listed, marked unavailable with the variable’s name and never its value.
What never leaves the app
These tools only mean something inside a live Vex session: they act on session state, a mission contract or a transcript that an external client has no part in. They are excluded from the export scope entirely, and the executor refuses them by name:
| Tool | Why it stays in |
|---|---|
| Memory tools | Session memory search and resolve, plus the long-term memory surface (suggest, search, get, history). An external agent brings its own memory. See Memory. |
| Mission tools | Mission drafting and stopping act on a mission contract, which lives in the app. See Missions. |
LoopDefer | Pauses Vex’s own autonomous loop until a wake time. There is no loop to park here. |
CompactApply | Applies a prepared summary to a Vex session’s context. |
PlanWrite | Writes the plan of a Vex session in plan mode. |
BoardCompose | Attaches a rendered board to an in-app assistant message. The MCP path has neither the renderer nor the turn loop. See Boards & Token Radar. |
execute_tool | The internal approval-resume envelope. It has no tool definition at all and is refused by name so the answer is the real reason rather than “unknown tool”. |
Mutating calls go through the broker
A project carries its own permission, restricted or full, and its own wallet selection: one EVM wallet and one Solana wallet, or none. No selection means no wallet, and every resolver fails closed rather than falling through to your primary wallet.
In a restricted project, a fund-moving call is answered with pendingApprovaland stops. An approval intent is written, it surfaces as an approval card in the Vex app, and the coding agent’s call blocks until a human decides. Nothing is signed or broadcast in between. The risk labels (info, low, medium, high, critical) and the Safety Contract apply unchanged. In a full project the same call runs without a per-call approval, exactly as a full-access session does in the app.
The gate is strict about what it proves before it enqueues anything: the project still exists, its permission and wallet selection have not changed since the call was admitted, and Vex is unlocked and ready rather than starting or shutting down. Edit a project’s scope while a call is in flight and the call is refused rather than parked against authority you have already changed.
Waiting calls are bounded at 32. Above that a new call is refused by name, telling you to decide the outstanding cards first, because a parked approval request is indistinguishable from a slow human and a hang is not actionable.
The external agent never holds keys and never signs. It proposes; Vex asks you; your machine signs. That is the same sentence as the rest of the product, which is the point.
The approval window
A Studio approval is valid for 1 hour, stamped at enqueue rather than at approval. Within that window you can leave the approval sitting there and the coding agent’s tool call waits with it. Past it, the approval expires and the call is answered with a refusal rather than executing against a market that has since moved. Each waiting call arms its own timer at the intent’s expiry, and a scheduled sweep is the floor under approvals whose process died.
This is why the Studio installer raises each client’s tool-call timeout where it can: the client must be willing to wait as long as the approval is. If you wired a client by hand, do that yourself. See Supported agents.
Studio only works while Vex is open and unlocked. An approval cannot be granted in an app that isn’t running, the socket isn’t listening either, and locking Vex closes every connection and refuses the actions still queued behind them. See Vex Studio.