Expose a pure Rust EmbeddedHarness API in codex-wasm-harness so downstream browser apps can depend on the crate directly without going through the demo-specific wasm_bindgen wrapper. Introduce trait seams for Responses transport, tool execution, and event delivery, move shared response/event types into dedicated modules, and keep BrowserCodex as a thin compatibility adapter so the existing browser demo continues to build and run unchanged.
2.7 KiB
Codex WASM Harness Prototype
This crate is the first browser-facing seam for a Codex harness prototype.
It now exposes two layers:
EmbeddedHarness: a pure Rust library API that downstream Rust/web repos can depend on directly.BrowserCodex: awasm_bindgenadapter that preserves the current browser demo API.
It does not yet call codex-core::run_turn or RegularTask::run. Instead, it
establishes the intended browser API shape:
- submit a prompt from JavaScript;
- stream Codex-shaped turn events back to the page; and
- resolve after a
turn_completeevent.
The sampler is currently implemented in Rust/WASM. The demo page uses a
deterministic local response by default, or passes the user's API key into the
WASM facade so Rust can make a direct browser fetch request to the Responses
API.
The API key field is for local prototype use only: it stores the key in browser
localStorage and sends it directly from the page. A production browser
integration should use a proxy or an ephemeral-token flow instead of persisting
long-lived API keys in the page origin.
The next step is to replace the callback boundary with a real model transport and then wire the facade to the Codex turn loop after host services are injectable.
Library Boundary
The intended downstream integration point is the pure Rust API:
EmbeddedHarnessResponsesClientToolExecutorEventSinkHarnessConfig
That allows downstream webapps to:
- depend on
codex-wasm-harnessfrom a Git branch or local path; - supply their own browser/runtime implementations for transport, tools, event rendering, or persistence; and
- keep app-specific browser glue out of the Codex repo.
The current BrowserCodex type remains a thin compatibility wrapper around
that library API so the demo page keeps working.
The real-core feature is an explicit compile probe for depending on
codex-core. It currently does not build for wasm32-unknown-unknown; the
first blocker is native Tokio/Mio networking pulled through the host-heavy
codex-core dependency graph.
Current Limitations
This is a boundary prototype, not a port of codex-core yet.
- It does not construct a
SessionorTurnContext. - It does not call
RegularTask::runorrun_turn. - It does not expose native Codex tools.
- It emits Codex-shaped events, but not the full protocol event set.
The immediate implementation value is that the browser API and demo page can be iterated independently while the host-heavy Codex services are moved behind browser-compatible traits.
Build Sketch
rustup target add wasm32-unknown-unknown
codex-rs/wasm-harness/scripts/build-browser-demo.sh
Then serve codex-rs/wasm-harness/examples and open /browser/index.html.