wasm32 Oz CLI prototype in a Node runtime (REMOTE-2264)#14104
Open
warp-dev-github-integration[bot] wants to merge 12 commits into
Open
wasm32 Oz CLI prototype in a Node runtime (REMOTE-2264)#14104warp-dev-github-integration[bot] wants to merge 12 commits into
warp-dev-github-integration[bot] wants to merge 12 commits into
Conversation
Co-Authored-By: Oz <oz-agent@warp.dev>
Co-Authored-By: Oz <oz-agent@warp.dev>
vorporeal
reviewed
Jul 21, 2026
| *Proposed changes:* | ||
| 1. Add a target-specific wasm entrypoint in the Warp app/agent ownership boundary and a `cdylib` build target. Export one JS-callable async operation (name and generated binding may follow repository conventions) that accepts `{prompt, api_key, server_url, model/config, timeout}` plus host capabilities, validates the input, creates the `AgentDriver` with an explicit `AgentDriverOptions` profile, and returns structured driver/session/terminal/error events. | ||
| 2. Make the AgentDriver setup wasm-safe by inventorying each dependency and using existing target carve-outs first: `local_fs` paths (cwd, file edits, snapshots, declarations, skill watchers, codebase indexing), `local_tty`/PTY and shell/process paths, MCP process startup, and any GUI/window/persistence bootstrap must be excluded or replaced with stable host-capability errors. Preserve the driver’s in-process MAA loop and session-sharing registration/consumer transport; provide only the minimal no-op or host-backed terminal/session implementation needed to prove the path. | ||
| 3. Add a `wasm_node` target feature/module in the HTTP and session-sharing paths. Define the host contract as `fetch(request) -> Promise<response>`, where request contains method, URL, headers, and bytes, and response exposes status, headers, and an async sequence of body chunks; add session-sharing connect/send/receive/close callbacks and a host log/event sink for stdout/stderr. The Node harness implements these contracts with Node LTS `fetch`, `AbortController`, and event capture. No browser DOM shim is permitted. |
Contributor
There was a problem hiding this comment.
i don't entirely understand this. i would have expected that we could basically polyfill HTTP requests at the reqwest layer, and not have the fact that this is running on Node really leak much into the application logic. am i misunderstanding things here?
Contributor
Author
There was a problem hiding this comment.
Addressed in ff8134f: application logic stays runtime-neutral, and Node fetch/stream handling is specified as an adapter behind the existing reqwest/http_client transport boundary. AgentDriver does not branch on Node types; the spec now requires the findings to record that boundary.
| - *Is a real Warp server required for tests?* No. The deterministic mock HTTP/SSE fixture is mandatory and proves the host boundary offline; a separately documented authenticated run against the configured Warp endpoint is an optional feasibility check when `WARP_API_KEY` is available. | ||
| - *What does “Node runtime” mean?* Use a supported Node LTS release with built-in `fetch` and `AbortController` (Node 20 or newer, matching the repository's existing Node-runtime minimum). No browser/DOM package is a required dependency. | ||
|
|
||
| *Risks / blast radius:* The app crate has broad GUI and platform dependencies, so an apparently small export can accidentally pull browser-only initialization or native-only code; keep all entrypoint and capability code behind target/feature gates and test import/run in a DOM-free Node process. `AgentDriver` may still transit a native-only dependency that the existing `local_fs`/`local_tty` carve-outs do not cover; the implementation must identify that dependency and either add a narrow wasm gate/stub or record it as the concrete partial/negative outcome before using the fallback. Session-sharing transport may have browser/WebSocket assumptions and must be host-backed or explicitly blocked with evidence. The existing reqwest event-source path may require a Node-specific stream adapter. MAA protocol changes or auth setup may make a real-server run unavailable; preserve the mock fixture and report that limitation rather than weakening the success criteria. Single-threaded wasm execution can block the JS event loop if synchronous work or unbounded streams are introduced; all host I/O must be Promise-based with explicit cancellation/timeouts. The prototype is an experiment, not a security boundary: document that host bindings define the actual authority and that no local tool capability is exposed. |
Contributor
There was a problem hiding this comment.
this ought to already be addressed by the cli cargo feature, which we use to put together a headless build of warp.
Contributor
Author
There was a problem hiding this comment.
Addressed in ff8134f: the build starts from the repository’s existing headless cli feature/configuration instead of inventing a second headless mode; the Node target-specific work is limited to the wasm entrypoint and transport boundary.
|
|
||
| *Risks / blast radius:* The app crate has broad GUI and platform dependencies, so an apparently small export can accidentally pull browser-only initialization or native-only code; keep all entrypoint and capability code behind target/feature gates and test import/run in a DOM-free Node process. `AgentDriver` may still transit a native-only dependency that the existing `local_fs`/`local_tty` carve-outs do not cover; the implementation must identify that dependency and either add a narrow wasm gate/stub or record it as the concrete partial/negative outcome before using the fallback. Session-sharing transport may have browser/WebSocket assumptions and must be host-backed or explicitly blocked with evidence. The existing reqwest event-source path may require a Node-specific stream adapter. MAA protocol changes or auth setup may make a real-server run unavailable; preserve the mock fixture and report that limitation rather than weakening the success criteria. Single-threaded wasm execution can block the JS event loop if synchronous work or unbounded streams are introduced; all host I/O must be Promise-based with explicit cancellation/timeouts. The prototype is an experiment, not a security boundary: document that host bindings define the actual authority and that no local tool capability is exposed. | ||
|
|
||
| *Validation & verification criteria* (must ALL pass before merge): |
Contributor
There was a problem hiding this comment.
fwiw, we're not merging any of this directly - this is intended to be a prototype for us to learn from. it's worth making this clear to the agent so that it doesn't stress about correctness, unit testing, integration testing, whatever. if it can run the manual test that was described in my initial prompt, that's sufficient.
Contributor
Author
There was a problem hiding this comment.
Addressed in ff8134f: the spec now explicitly frames this as an experiment for learning, with a real authenticated manual AgentDriver run plus findings as the required proof. Tests and local checks are optional confidence aids, not production correctness or test-artifact deliverables.
Comment on lines
+62
to
+63
| 3. *Explicit startup configuration:* A test invokes the export directly with a prompt/API key/config object and proves that changing the Node process argv/environment after invocation does not alter the wasm request; a missing API key and empty prompt each produce the specified structured input error. No API-key value appears in stdout, stderr, JSON results, fixtures, or logs. | ||
| 4. *AgentDriver construction:* A focused wasm/Node integration test proves that the exported operation creates `AgentDriverOptions` and `AgentDriver`, passes authentication/configuration, reaches the driver run, and does not call the native `warp::run()`/GUI `initialize_app` path. If construction fails, the test captures the concrete error and the findings classify the result as partial/negative before any fallback is counted. |
Contributor
There was a problem hiding this comment.
as mentioned in my other comment, i have zero need or desire for any sort of test artifacts. i just want a thing that works as a proof of concept. the agent should only write tests to the extent that they help it have confidence, as it works, that it wrote correct library code - i require zero tests.
Contributor
Author
There was a problem hiding this comment.
Addressed in ff8134f: no broad Rust/Node test suite or test artifacts are required. Any focused checks are optional implementation confidence aids; the acceptance contract is the manual live run and findings.
| 5. *Session-sharing path:* The happy-path fixture asserts conversation/session registration, host transport connect/send/receive/close callbacks, and the first streamed MAA response event through `AgentDriver`. The result must expose session events or a documented equivalent. A direct MAA fallback is explicitly marked as not satisfying this criterion. | ||
| 6. *AgentDriver dependency inventory:* Tests or compile-time gates cover each dependency boundary: `local_fs` cwd/file-edit/snapshot/declarations/skill-watcher/indexing paths, `local_tty`/PTY/shell/process paths, MCP startup, GUI/window/persistence bootstrap, and session-sharing transport. Each is either excluded by wasm cfg, replaced by a no-op/host callback, or returns the stable `unsupported_capability` error; the findings list the exact file/module and observed behavior. | ||
| 7. *Host HTTP contract:* A Node test with a local mock server asserts the exact method, URL, headers, body, and abort behavior received from the wasm host bridge, and returns a streamed response in chunks. The AgentDriver path consumes the chunks and emits a terminal result. | ||
| 8. *MAA happy path:* The mock SSE fixture produces the minimal valid response sequence; the AgentDriver-first operation returns a success/terminal event containing the expected text, and stdout/stderr capture contains only the documented non-secret events. If AgentDriver is blocked, the direct fallback must pass the same request/event checks but be reported as a partial result without session-sharing proof. |
Contributor
There was a problem hiding this comment.
what do you mean by "mock SSE fixture" here? i don't know why we'd mock anything out around the MAA stream.
Contributor
Author
There was a problem hiding this comment.
Addressed in ff8134f: the mandatory mock SSE fixture is removed. The required MAA proof uses a real configured Warp endpoint; an ephemeral local HTTP server or captured response is allowed only for optional transport debugging and cannot substitute for AgentDriver/session-sharing validation.
Co-Authored-By: Oz <oz-agent@warp.dev>
…E-2264) Add a proof-of-concept that compiles the Warp agent multi-agent API (MAA) request/response protocol to wasm32-unknown-unknown and runs one authenticated agent run in a DOM-free Node runtime. The approved spec makes the full AgentDriver the primary path. That path is blocked on wasm32-unknown-unknown by a concrete dependency: AgentDriver::new needs a live ModelContext/AppContext (persistence, auth, server clients, watchers, GUI views) and a TerminalDriver, whose PTY/shell backend is gated behind local_tty — a feature the build script only enables on platforms with a real TTY, absent on wasm. app/src/lib.rs LaunchMode::CommandLine panics for CLI on wasm for this reason. Per the spec, the direct MAA request/client loop fallback was implemented; it does not validate session sharing (owned by the AgentDriver/conversation-consumer path). New isolated cdylib crate crates/wasm_node_proto: - Exports #[wasm_bindgen] run_multi_agent(config, host) that builds a canonical warp_multi_agent_api::Request (same wire format as the CLI), POSTs it to the live /ai/multi-agent endpoint via a host-injected fetch, and streams/decodes ResponseEvents (StreamInit/ClientActions/StreamFinished). - Depends only on the prost MAA types + wasm-bindgen/base64/serde. No dependency on the warp app crate, http_client, reqwest, web_sys, warpui, or any GUI/PTY/fs code. reqwest's wasm backend hard-requires web_sys::window(); Node has no window and the spec forbids a DOM shim, so HTTP crosses an explicit host fetch(request)->Promise<response> boundary with streamed chunks. The harness owns AbortController/timeout; Node-ness never leaks into the wasm crate. - Explicit capability boundary: no fs/pty/shell/subprocess/MCP/watcher/indexing/ snapshot/GUI code is compiled in; a model-requested tool call is surfaced as an unsupported_capability observation, never a native fallback. - Validated: cargo check + clippy clean for wasm32-unknown-unknown; 5 focused unit tests (SSE decode/accumulate, request build round-trip, input validation, tool-call detection) pass on native. script/wasm/build-node builds the cdylib + runs wasm-bindgen --target nodejs. script/wasm/node-harness.mjs imports the loader, supplies Node fetch + AbortController + a web-stream reader, redacts the API key, and exits nonzero on structured failure. Manual proof against https://app.warp.dev: the wasm module builds, loads in Node 25, and makes a real authenticated POST that returns a structured 403 (edge-gated /ai/* path; the available API key is also 401 on /api/v1/*). The structured-failure path is proven; a fully-successful streamed terminal event against production is blocked by edge bot protection + credential limitations in this environment, reported as a partial result (no mock substituted). Full findings, the AgentDriver dependency inventory, the wasm32-vs-WASI comparison, resource observations, and the next three engineering steps are in agents/specs/REMOTE-2264: findings.md. Co-Authored-By: Oz <oz-agent@warp.dev>
warp-dev-github-integration
Bot
changed the title
Contributor
|
@warp-dev-github-integration[bot] I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
This PR adds a standalone wasm_node_proto crate, Node build script, Node harness, and findings/spec documents for a wasm32 direct-MAA prototype. No approved external spec context was attached, so I reviewed the implementation against the provided diff, PR description, repository guidance, and supplemental security checks.
Concerns
- The request advertises local filesystem/shell/MCP-style tools even though the wasm path cannot execute them or send real unsupported-capability tool results, so tool-requesting runs can stall or be misrepresented.
- Malformed SSE events and streams that disconnect before
StreamFinishedcan be reported as successful runs instead of deterministic structured errors. - The Node harness clears its timeout immediately after
fetch()resolves headers, so--timeout-msdoes not protect the streamingbody.read()loop from hanging.
Security
- The exported wasm path accepts any
http(s)server_root_urland sends the bearer API key to it. Restrict or explicitly gate non-Warp/non-local roots to reduce accidental token exfiltration.
Verdict
Found: 0 critical, 3 important, 1 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
| supports_parallel_tool_calls: true, | ||
| planning_enabled: true, | ||
| supports_create_files: true, | ||
| supported_tools: local_session_tools(), |
Contributor
There was a problem hiding this comment.
unsupported_capability response; advertise only wasm-supported capabilities or wire explicit unsupported tool results before enabling them.
Comment on lines
+449
to
+455
| // Stream ended without an explicit Finished event. | ||
| let mut res = acc.to_result(); | ||
| if res.status == "pending" { | ||
| res.status = "success".to_string(); | ||
| res.ok = true; | ||
| res.finished_reason = Some("stream_ended".to_string()); | ||
| } |
Contributor
There was a problem hiding this comment.
StreamFinished as success hides truncated SSE responses and disconnects. Return a structured error here unless a terminal Finished::Done was decoded, so malformed streams and early disconnects satisfy the documented failure behavior instead of looking like successful runs.
Comment on lines
+136
to
+138
| } finally { | ||
| if (timer) clearTimeout(timer); | ||
| } |
Contributor
There was a problem hiding this comment.
finally means it only covers the initial fetch() promise, not the streamed body.read() calls. If the server sends headers and then stalls, --timeout-ms no longer aborts the run; keep the controller/timer alive until the wasm stream finishes or fails.
Comment on lines
+150
to
+151
| if !server_root_url.starts_with("http://") && !server_root_url.starts_with("https://") { | ||
| return Err("server_root_url must be an http(s) URL".to_string()); |
Contributor
There was a problem hiding this comment.
💡 [SUGGESTION] [SECURITY] Any http(s) root passes validation and then receives the bearer API key in build_fetch_init. Consider restricting this to known Warp hosts plus explicit localhost/dev overrides, or requiring an opt-in flag for arbitrary origins so a misconfigured server_root_url cannot exfiltrate the key.
Follow reviewer guidance ("AppContext is very much available on wasm"; "make
TerminalDriver a no-op") and genuinely pursue the full AgentDriver path on
wasm32-unknown-unknown, on the same PR/branch.
What now works:
- The warp app crate compiles for wasm32-unknown-unknown (headless/default
features), confirming AgentDriver/agent_sdk/ServerApi/AuthState are available
on the wasm target.
- New warpui::platform::headless::new_headless_app(assets) -> App constructs a
headless App (with AppContext) WITHOUT running the blocking platform event
loop. On wasm the foreground/background executors schedule via
wasm_bindgen_futures::spawn_local, so a #[wasm_bindgen] pub async fn can
spawn work on the app's foreground executor and await it (the JS event loop
polls it as the async fn yields). No DOM/window/document required. A real
Node 25 run confirmed new_headless_app succeeds end-to-end.
- TerminalDriver::create_no_op (wasm-gated) pre-resolves the bootstrap channel
to Ok(()) (synthetically advanced to the bootstrapped stage, no PTY), so
AgentDriver's terminal dependency is satisfiable without local_tty.
- New crates/warp_wasm_node cdylib re-exports run_agent_driver_wasm (defined in
app/src/wasm_node_driver.rs, which owns the pub(crate) AgentDriver types) for
wasm-bindgen --target nodejs.
Concrete next blocker (surfaced by a real Node run): the trimmed init reaches
features::init_feature_flags(), which reads the PrivatePreferences singleton; a
trimmed init does not register it, so the run panics at
PrivatePreferences::as_ref. Because the app crate builds with panic = "abort"
on wasm, catch_unwind cannot catch this — each missing singleton aborts.
AgentDriver::new/run_internal reads a long tail of such singletons
(PublicPreferences, SettingsManager, AIExecutionProfilesModel,
BlocklistAIPermissions, UserWorkspaces, ApiKeyManager, skills/MCP/environment
managers, ...) that initialize_app registers and a trimmed init must reproduce
(several are sqlite/native-backed). Two further blockers remain: http_client's
wasm transport uses web_sys::window() (browser-only), so the MAA request needs
a host-fetch injection; and production /ai/* is edge-gated (403) with the
available key unauthorized (401). The direct-MAA fallback crate
(crates/wasm_node_proto) remains as a documented fallback.
Verified: cargo check + clippy -D warnings clean for wasm32-unknown-unknown on
warp, warp_wasm_node, and wasm_node_proto; format --check clean; warp_wasm_node
builds to a 234 MB debug wasm + wasm-bindgen nodejs loader; real Node run
reaches stage constructed_app and surfaces the precise trimmed_init blocker.
Findings updated in agents/specs/REMOTE-2264: findings.md.
Co-Authored-By: Oz <oz-agent@warp.dev>
…ow blocker (REMOTE-2264) Second pass per reviewer course-correction: pivot from the parallel new_headless_app/trimmed-init to reusing the REAL app init path. - Extract run_app_init (the shared init body: full singleton surface + initialize_app + launch()) from run_internal's app_builder.run closure, so both the platform event-loop path and a wasm-async path call the same code. - Add run_command_line_wasm(launch_mode) -> App (wasm-gated): same pre-AppContext setup as run_internal, then drives run_app_init through a headless App via new_headless_app (no blocking event loop) instead of AppBuilder::run. The #[wasm_bindgen] pub async fn run_agent_driver_wasm builds a LaunchMode::CommandLine and calls it. - Flip launch()'s LaunchMode::CommandLine wasm arm from panic! to route to agent_sdk::run (gated out std::process::exit). Concrete blocker (precise, from a real Node 25 run): the real run_app_init/initialize_app path panics with "Can't find the global Window" from gloo_utils::window() — the standard wasm init path assumes a browser environment (browser global), unavailable in a DOM-free Node runtime. Additionally ai::agent_sdk (the in-process CLI/agent path) is gated #[cfg(not(target_family="wasm"))] by a large native-only dependency surface (comfy_table, inquire, command::r#async, ai::artifact_download, ai::skills/fs, ai::bedrock_credentials, ai::blocklist::finalize_recording_for_conversation, ai::mcp::file_based_manager, server::server_api::harness_support file uploads, presigned_upload, ai::ambient_agents::task::HarnessModelConfig, ...) that is cfg(not(target_family="wasm"))-gated throughout app/src/ai/. So reusing run_internal on wasm in Node requires (a) replacing/stubbing the gloo::utils::window() / browser-global reads in the init path with host-backed or no-op equivalents for a DOM-free runtime, and (b) carving out the agent_sdk native-only dependency surface so agent_sdk::run compiles on wasm. The headless App/AppContext still constructs fine (new_headless_app succeeds); the blocker is the browser-env assumption in the shared init + the agent_sdk gate. Verified: wasm cargo check + clippy -D warnings clean on warp/warp_wasm_node; format --check clean; warp_wasm_node builds + wasm-bindgen nodejs loader produced; real Node run reaches run_app_init and surfaces the precise gloo::utils::window() panic. Findings updated. Co-Authored-By: Oz <oz-agent@warp.dev>
… on headless wasm (REMOTE-2264)
Per requester direction: in make_absolute_url (crates/warp_util/src/assets.rs),
instead of unconditionally calling gloo::utils::window().location().origin()
(which panics with "Can't find the global Window" in a DOM-free Node runtime),
add a runtime-set headless asset origin (warp_util::assets::set_headless_asset_origin)
that the app registers from ChannelState::server_root_url() at startup. When set,
make_absolute_url uses it; otherwise it falls back to window().location().origin()
(browser web-GUI path unchanged) and then to an empty origin rather than panicking.
warp_util cannot depend on warp_core (cycle), so the origin is injected via a
OnceLock static rather than reading ChannelState directly. run_command_line_wasm
calls set_headless_asset_origin(ChannelState::server_root_url()) before run_app_init
so WarpConfig::new's default-theme asset URL absolutization succeeds.
Result: the Node run gets PAST the gloo::utils::window() panic. The next concrete
blocker is a different browser-global: gloo_storage::LocalStorage::raw ("no window")
reached via settings::init::register_all_settings -> BlockListSettings::register ->
ShowJumpToBottomOfBlockButton::read_from_preferences -> LocalStoragePreferences
(the wasm settings backend assumes browser localStorage). Same class of
browser-global assumption, now at the settings-init stage.
Verified: wasm cargo check + clippy -D warnings clean on warp/warp_wasm_node;
native clippy clean on warp_util; format --check clean; warp_wasm_node builds +
runs in Node (passes make_absolute_url, reaches settings::init, surfaces the
next gloo_storage::LocalStorage panic with a full backtrace).
Co-Authored-By: Oz <oz-agent@warp.dev>
…ker is gloo_storage::LocalStorage (REMOTE-2264) Co-Authored-By: Oz <oz-agent@warp.dev>
…/CLI (REMOTE-2264)
Per requester direction: use an in-memory UserPreferences impl for the
headless wasm/CLI path in place of LocalStoragePreferences (which needs
browser localStorage). Added a HEADLESS_WASM_PREFERENCES AtomicBool flag
(settings::set_headless_wasm_preferences) that, when set, makes
init_platform_native_preferences and init_public_user_preferences use
InMemoryPreferences instead of LocalStoragePreferences on wasm. The browser
web-GUI path leaves the flag false and keeps LocalStoragePreferences unchanged.
run_command_line_wasm calls set_headless_wasm_preferences() before the
preferences init so the backend selection sees the flag.
Result: the Node run gets PAST the gloo_storage::LocalStorage "no window"
panic. It now reaches: settings migration completes, API key auth works
("Authenticating via API key"), ChannelState prints the full config. The next
concrete blocker is gloo::utils::window() again, this time from
warpui_core::platform::wasm::parsed_user_agent (reads window().navigator()
.user_agent() to detect the OS), reached via OperatingSystem::get() ->
Keystroke::parse() -> FixedBinding::new -> ai::blocklist::block::
toggleable_items::init -> ai::init -> initialize_app. Same class of
browser-global assumption, now in the warpui_core wasm platform layer.
Verified: wasm cargo check + clippy -D warnings clean; format --check clean;
warp_wasm_node builds + runs in Node (passes LocalStorage, reaches API key
auth, surfaces the next parsed_user_agent panic with a full backtrace).
Co-Authored-By: Oz <oz-agent@warp.dev>
…window (REMOTE-2264)
Per requester direction: make warpui_core::platform::wasm::parsed_user_agent
degrade gracefully — return a default OS of Linux when there is no browser
window (DOM-free runtime) instead of panicking. Check for the window global's
existence via js_sys::Reflect::get on the JS global before calling
gloo::utils::window() (which throws when no window). Keep the real browser
behavior (read window().navigator().user_agent()) when a window exists.
Also fix user_agent() to check for the window first (same pattern).
Added js-sys and wasm-bindgen as wasm-only deps to warpui_core for the
Reflect::get / JsValue checks.
Result: the Node run gets PAST the parsed_user_agent panic. It now reaches:
settings migration completes, API key auth, ChannelState config, "Initializing
app services", the launch() CommandLine arm executes ("agent_sdk not compiled
into this wasm build"), and "Cleaning up index metadata from SQLite". The next
concrete blocker is http_client::Client::include_warp_http_headers ->
gloo::utils::window() (the same-origin check reads window().hostname()), reached
via an actual GraphQL request (GetAvailableHarnesses -> send_graphql_request ->
Client::post -> include_warp_http_headers). This is the host-fetch transport
blocker — the app is now making a real authenticated server request and the
http_client wasm path needs web_sys::window() for the same-origin check.
Verified: wasm cargo check + clippy -D warnings clean; format --check clean;
warp_wasm_node builds + runs in Node (passes parsed_user_agent, reaches actual
GraphQL request, surfaces the http_client include_warp_http_headers panic).
Co-Authored-By: Oz <oz-agent@warp.dev>
…window (REMOTE-2264)
Per requester direction: on wasm, make http_client::Client::include_warp_http_headers
default to true (include Warp headers / skip the same-origin check) when there is
no browser window, keeping the real browser behavior (read
window().location().hostname() for the same-origin check) when a window exists.
Check for the window global's existence via js_sys::Reflect::get on the JS global
before calling gloo::utils::window() (which throws when no window). When no window
is found (DOM-free runtime like Node), return true so the request proceeds — the
headless CLI/Node path always targets the Warp server, so including the headers is
correct. Added js-sys and wasm-bindgen as wasm-only deps to http_client.
Result: the Node run gets PAST the include_warp_http_headers panic. The full
initialize_app + launch() path now completes without any browser-global panics.
The structured result returns {"ok":true,"stage":"app_init"}. The run reaches:
settings migration, API key auth, ChannelState config, "Initializing app services",
the launch() CommandLine arm (which logs "agent_sdk is not compiled into this wasm
build" — the agent_sdk native-only gate remains the next blocker for an actual
agent run), "Cleaning up index metadata from SQLite", and the spawned async tasks
(harness availability refresh, etc.) no longer crash on the HTTP path.
Verified: wasm cargo check + clippy -D warnings clean; format --check clean;
warp_wasm_node builds + runs in Node (completes app_init with ok:true, no panics).
Co-Authored-By: Oz <oz-agent@warp.dev>
…e real MAA request (REMOTE-2264) Un-gate ai::agent_sdk on wasm and carve out its native-only dependency tail so agent_sdk::run compiles and drives a real MAA request on wasm32-unknown-unknown. Carve-outs (all cfg(not(target_family="wasm"))-gated, browser + native paths unchanged): - Gated 20 native-only agent_sdk submodules: driver, agent_management, ambient, api_key, artifact, artifact_upload, common, environment, federate, harness_support, mcp, memory_store, model, output, profiles, provider, runner, schedule, secret, admin — all depend on comfy_table, inquire, tokio, command::r#async, or native-only ai:: submodules (skills/fs, mcp::file_based_manager, blocklist::finalize_recording_for_conversation, bedrock_credentials, etc.). - Gated native-only functions in mod.rs: dispatch_command, run_agent, build_merged_config_and_task, build_server_side_task, reconcile_task_harness, resolve_prompt, run_task, launch_command, refresh_auth_and_dispatch, format_skill_resolution_error, AgentDriverRunner struct + impls. - Gated native-only imports and added allow(dead_code)/allow(unused_imports) on wasm for modules/functions only used by native code (config_file, mcp_config, oauth_flow, setup_observability, text_layout, telemetry, retry re-exports). Wasm dispatch_command: - Handles AgentCommand::Run via the direct MAA request path (warp_multi_agent_client::generate_multi_agent_output), bypassing the full AgentDriver which depends on native-only backends. Builds a canonical warp_multi_agent_api::Request (same wire format as the CLI), gets the ServerApi's base_client, and spawns the MAA request on the foreground executor (spawn_local on wasm). Other CLI commands return "not supported on wasm". - Added pub base_client() accessor on ServerApi for the wasm MAA path. - Made run() call dispatch_command directly on wasm (bypasses launch_command's native auth flow). Result: agent run --prompt hello now reaches a real authenticated MAA request through the real agent_sdk::run → launch() → dispatch_command → generate_multi_agent_output path on wasm32-unknown-unknown in Node! The Node 25 run shows: "Agent run dispatched via direct MAA path on wasm" → "Sending MAA request for prompt: hello" → MAA stream error: 403 (the production /ai/* edge gate, same as documented — not a prototype defect) → "MAA stream completed". Verified: wasm cargo check + clippy -D warnings + format --check all clean; warp_wasm_node builds (234 MB debug wasm) + runs in Node (reaches real MAA request, gets 403 from production edge, stream completes cleanly). Co-Authored-By: Oz <oz-agent@warp.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Prototype (REMOTE-2264): compiles the Warp agent multi-agent API (MAA) request/response protocol to
wasm32-unknown-unknownand runs one authenticated agent run (hello) in a DOM-free Node runtime. This is a learning prototype, not intended for direct merge (per the originating thread).The approved spec makes the full
AgentDriverthe primary path. That path is blocked onwasm32-unknown-unknownby a concrete dependency:AgentDriver::newneeds a liveModelContext/AppContext(persistence, auth, server clients, watchers, GUI views) and aTerminalDriver, whose PTY/shell backend is gated behindlocal_tty— a feature the build script only enables on platforms with a real TTY, absent on wasm.app/src/lib.rsLaunchMode::CommandLinepanics for CLI on wasm for this reason. Per the spec, the direct MAA request/client loop fallback was implemented. It does not validate session sharing (owned by theAgentDriver/conversation-consumer path); that lost capability and the path to recover it are documented in the findings.What's in this PR
crates/wasm_node_proto(new isolatedcdylib+rlib): exports#[wasm_bindgen] run_multi_agent(config, host)that builds a canonicalwarp_multi_agent_api::Request(same wire format as the CLI), POSTs it to the live/ai/multi-agentendpoint via a host-injectedfetch, and streams/decodesResponseEvents (StreamInit/ClientActions/StreamFinished). Depends only on the prost MAA types +wasm-bindgen/base64/serde— no dependency on thewarpapp crate,http_client,reqwest,web_sys,warpui, or any GUI/PTY/fs code.script/wasm/build-node: builds the cdylib + runswasm-bindgen --target nodejs.script/wasm/node-harness.mjs: imports the loader, supplies Nodefetch+AbortController+ a web-stream reader, redacts the API key, exits nonzero on structured failure.agents/specs/REMOTE-2264: findings.md: full findings (build/run commands, AgentDriver dependency inventory + gating, session-sharing observations, fallback/blocker evidence, wasm32-vs-WASI comparison, resource observations, next 3 engineering steps).Transport design (the key learning)
reqwest's wasm backend hard-requires
web_sys::window()(a browser global). Node has nowindowand the spec forbids a DOM shim. So HTTP crosses an explicit host contracthost.fetch(url, init) -> Promise<{status, headers, body}>wherebody.read() -> Promise<{done, value?: Uint8Array}>mirrors a webReadableStreamreader. The Node harness implements it with Node's globalfetch+AbortController. Application logic (the wasm crate) never branches on Node types — it only calls the hostfetch. This is the "polyfill HTTP at the transport layer" approach, expressed as an explicit host boundary rather than a reqwest polyfill (impossible withoutwindow). The capability boundary is explicit: no fs/pty/shell/subprocess/MCP/watcher/indexing/snapshot/GUI code is compiled in; a model-requested tool call surfaces as anunsupported_capabilityobservation, never a native fallback.Verification
cargo check --target wasm32-unknown-unknown -p wasm_node_proto: pass.cargo clippy --target wasm32-unknown-unknown -p wasm_node_proto -- -D warnings: pass.cargo test -p wasm_node_proto: 5/5 pass (SSE decode/accumulate → terminal result, finished-reason classification, tool-call detection, request build round-trip, input validation)../script/format --check+./script/check_no_inline_test_modules: pass../script/wasm/build-node: pass (produces Node loader + 8.4 MB wasm).node script/wasm/node-harness.mjs --prompt hello --api-key "$WARP_API_KEY" --server-root-url https://app.warp.dev: the wasm module builds, loads in Node 25, and makes a real authenticated POST that returns a structured403 Forbidden(the production/ai/*path is edge-gated for Node/curl; the available API key is also401on/api/v1/*). The structured-failure path is proven and exits nonzero; a fully-successful streamed terminal event against production is blocked by edge bot protection + credential limitations in this environment, reported as a partial result (no mock SSE fixture substituted). See the findings for the isolation probes.The full workspace
./script/presubmitwas not run (60+ GUI/platform crates; out of scope for an isolated prototype crate in this environment). Scoped checks above all pass. The existing browser wasm build and native CLI path are untouched (wasm_node_protois a new, isolated crate; no shared crate modified).Originating thread: https://slack.com/archives/C0BDQDW8V5E/p1784671459475239
Co-Authored-By: Oz oz-agent@warp.dev