Codex CLI for WebAssembly Development: Rust-to-Wasm Workflows, Wassette MCP, and the Component Model

WebAssembly has crossed the threshold from browser curiosity to production infrastructure. The 2026 State of WebAssembly survey reports 67% of respondents now run Wasm in production, with server-side deployments overtaking browser-only use for the first time at 52%¹. WASI Preview 2 stabilised in April 2026², the Component Model is shipping in Wasmtime and Spin, and Rust remains the dominant source language for Wasm modules.

Codex CLI — itself built in Rust³ — sits naturally in this ecosystem. This article covers three layers of the Codex-Wasm intersection: using Codex CLI to develop WebAssembly modules, using Wasm components as tools inside Codex via Wassette, and the emerging pattern of distributing agent capabilities as portable Wasm binaries.

Setting Up the Wasm Toolchain

A Rust-to-Wasm project needs rustup, the wasm32-unknown-unknown or wasm32-wasip2 target, wasm-pack (v0.13+), and wasm-bindgen (v0.2.120 as of April 2026)⁴. The sandbox must be able to reach these tools.

Sandbox Configuration

Codex CLI’s sandbox restricts filesystem and network access by default. For Wasm cross-compilation, you need the Rust toolchain directories on the allow list and network access for cargo registry fetches during the first build:

# .codex/config.toml (project-scoped)
sandbox_mode = "workspace-write"

[sandbox]
add_dirs = [
  "~/.rustup:ro",
  "~/.cargo:rw",
]

On Linux, Codex uses Bubblewrap for isolation⁵. The add_dirs entries mount the Rust toolchain read-only and the Cargo cache read-write, so cargo build --target wasm32-wasip2 can resolve dependencies and compile without escaping the sandbox boundary.

AGENTS.md for Wasm Projects

An AGENTS.md file in the repository root anchors Codex’s behaviour to Wasm conventions:

# AGENTS.md

## Build
- Target: `wasm32-wasip2` for WASI components, `wasm32-unknown-unknown` for browser modules.
- Build command: `cargo component build --release` (WASI) or `wasm-pack build --target web` (browser).
- Always run `cargo clippy --target <target>` before committing.

## Testing
- Use `cargo component test` for WASI component tests.
- For browser targets, run `wasm-pack test --headless --chrome`.

## Conventions
- Export interfaces via WIT files in the `wit/` directory.
- Never commit `.wasm` binaries — build artefacts belong in CI.
- Pin wasm-bindgen version in Cargo.toml to match the CLI version exactly.

This prevents the model from defaulting to native compilation or generating code that targets the wrong Wasm interface.

Rust-to-Wasm Workflow Patterns

Browser Module Generation

The most common pattern is scaffolding a Rust library that compiles to a browser-consumable Wasm module via wasm-pack:

codex exec -a full-auto \
  "Create a Rust library that exports a markdown_to_html function \
   using pulldown-cmark. Target wasm32-unknown-unknown with wasm-pack. \
   Include wasm-bindgen annotations and a package.json for npm publishing. \
   Run wasm-pack build --target web and verify the pkg/ output compiles."

Codex will scaffold Cargo.toml with crate-type = ["cdylib"], add wasm-bindgen annotations, configure wasm-pack, and run the build inside the sandbox. The structured output from codex exec --json reports reasoning-token usage⁶, useful for tracking cost on iterative Wasm compilation cycles.

WASI Component Model

WASI Preview 2’s Component Model introduces WIT (WebAssembly Interface Types) — a formal type system for inter-module communication covering strings, records, enums, options, results, and resource handles⁷. Codex CLI can scaffold WIT interfaces and the corresponding Rust implementations:

codex exec -a full-auto \
  "Create a WASI component that exports a 'process' function \
   accepting a string and returning a result<string, string>. \
   Write the WIT file in wit/world.wit, implement in src/lib.rs \
   using cargo-component, and run cargo component build --release."

The wasm32-wasip2 target — stabilised in Rust 1.85⁸ — generates a Component Model binary that any WASI-compliant runtime (Wasmtime, Spin, WasmEdge) can load.

flowchart LR
    A[WIT Interface<br/>wit/world.wit] --> B[Rust Implementation<br/>src/lib.rs]
    B --> C[cargo component build]
    C --> D[.wasm Component]
    D --> E[Wasmtime]
    D --> F[Spin]
    D --> G[Wassette MCP]

Wassette: Wasm Components as Agent Tools

The most distinctive angle in the Codex-Wasm story is Wassette — Microsoft’s MCP server that executes WebAssembly Components as agent tools⁹. Released in August 2025 and now at v0.3.4, Wassette translates each exported function from a Wasm Component into an individual MCP tool, giving Codex CLI access to sandboxed, portable capabilities.

Configuration

Add Wassette as an MCP server for Codex CLI:

codex mcp add wassette -- wassette serve --stdio

Or configure it directly in config.toml:

[mcp_servers.wassette]
command = "wassette"
args = ["serve", "--stdio"]

Once registered, Codex discovers all tools exposed by loaded Wasm components via /mcp in the TUI¹⁰.

Fetching Components from OCI Registries

Wassette can pull Wasm Components directly from OCI-compliant container registries¹¹. This means an agent can dynamically obtain a tool, execute it in a Wasmtime sandbox with deny-by-default permissions, and discard it afterwards — no host-level installation, no persistent state, no supply-chain risk from native binaries:

wassette serve --stdio \
  --component oci://ghcr.io/example/csv-parser:latest \
  --component oci://ghcr.io/example/json-validator:latest

Each component runs with browser-grade isolation: no filesystem access, no network access, and no ambient authority unless explicitly granted through Wassette’s permission system¹².

Building Custom Tools

The development loop for creating Wasm-based agent tools combines both sides of the Codex-Wasm story:

Scaffold the Wasm component with Codex CLI, using WIT to define the tool interface.
Build with cargo component build --release.
Test with the MCP Inspector: npx @modelcontextprotocol/inspector --cli wassette serve --stdio --component ./target/wasm32-wasip2/release/my_tool.wasm.
Publish to an OCI registry: wasm-tools compose and oras push.
Consume in Codex CLI via the Wassette MCP server.

This creates a virtuous cycle: Codex CLI generates the Wasm tools that Codex CLI then uses.

The Wasm Tool Distribution Model

The broader pattern emerging in 2026 is Wasm as the universal tool format for AI agents. Instead of shipping capabilities as Python packages, npm modules, or Docker containers, teams distribute portable WebAssembly Components that any MCP-compatible agent can load¹³.

The advantages for agent tooling are structural:

Property	Native Binary	Docker Container	Wasm Component
Startup latency	~0ms	500ms–2s	~5ms
Isolation	None	Process-level	Capability-based
Portability	Platform-specific	Linux-only (mostly)	Universal
Size	Varies	50MB+	Typically <5MB
Supply-chain auditability	Low	Medium	High (single binary)

Fermyon’s Spin v3.5 shipped the first release candidate for WASI Preview 3 with native async I/O¹⁴, and WASI 1.0 — the stable long-term standard — is planned for later in 2026¹⁵. As these standards solidify, the Wasm Component becomes an increasingly attractive distribution format for the agent skills ecosystem.

Model Selection and Cost

Wasm development involves two distinct phases with different model requirements:

Scaffolding and WIT design: Use o4-mini or gpt-5.3-codex-spark for fast iteration on interface definitions and boilerplate. The 128k context window is sufficient for most single-component work¹⁶.
Complex implementation: Switch to gpt-5.4 or gpt-5.5 for implementing algorithms, optimising hot paths, or debugging cross-compilation issues where deeper reasoning pays off¹⁷.

Profile switching makes this seamless:

[profiles.wasm-scaffold]
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "medium"

[profiles.wasm-deep]
model = "gpt-5.5"
model_reasoning_effort = "high"

Current Limitations

No in-sandbox Wasm runtime testing: Codex CLI’s sandbox does not ship Wasmtime or Spin. You can compile Wasm modules inside the sandbox, but running them requires add_dirs access to a host-installed runtime or a PostToolUse hook that invokes the runtime externally.
WIT complexity: The Component Model’s type system is expressive but verbose. Models occasionally generate invalid WIT syntax, particularly around resource handles and async interfaces. AGENTS.md constraints with WIT examples help.
wasm-bindgen version pinning: A mismatch between the wasm-bindgen crate version and the CLI version produces cryptic build failures. Pin both explicitly in your AGENTS.md.
Wassette is stdio-only for CLI: ⚠️ Wassette supports HTTP transport for some clients, but Codex CLI integration currently uses stdio transport only. HTTP transport support for Codex CLI’s MCP configuration is available but untested with Wassette specifically.

Citations

State of WebAssembly Survey 2026 — 67% production adoption, server-side overtaking browser-only. ↩
WASI Preview 2 Stability Announcement — Listed as stable April 28, 2026. ↩
OpenAI Codex CLI — Built in Rust — Rust implementation is the maintained CLI. ↩
wasm-bindgen v0.2.120 — Released April 28, 2026. ↩
Codex CLI Sandbox — Bubblewrap on Linux — Linux sandbox isolation details. ↩
Codex exec –json Reasoning Tokens — v0.130.0 changelog, May 8, 2026. ↩
Component Model and WIT — Bytecode Alliance roadmap for the Component Model type system. ↩
Rust wasm32-wasip2 Target — Stabilised wasm64 and wasip2 targets in Rust 1.85. ↩
Wassette: WebAssembly-based tools for AI agents — Microsoft Open Source Blog, August 2025. ↩
Codex CLI MCP Configuration — MCP server setup in config.toml. ↩
Wassette OCI Registry Support — Fetching Wasm Components from OCI registries. ↩
Wassette Security Model — Deny-by-default permission system. ↩
Wasm as Universal Tool Format — The New Stack on WebAssembly solving AI agent security gaps. ↩
Spin v3.5 WASI Preview 3 RC — Fermyon Spin with async I/O in the Component Model. ↩
WASI 1.0 Roadmap — Stable long-term standard planned for 2026. ↩
Codex-Spark 128k Context — GPT-5.3-Codex-Spark specifications. ↩
Codex CLI Model Selection — Model capabilities and routing guidance. ↩