feat(wasm): run bashkit as a wasm component with no JS and no WASI

[chaliy]

What changed

Bashkit can now run as a WebAssembly component in a host with no JS engine
and no WASI — plain wasmtime, and by extension the no_std wasmtime that
hyperlight-wasm compiles
into a Hyperlight micro-VM
guest. examples/hyperlight/ builds that guest and runs a script through it.

The interpreter needed nothing: it already runs single-threaded over an
in-memory VFS and makes no syscalls. Four dependencies assumed a JS host, and
all four now sit behind a new wasm_js feature (on for the JS packages, off for
everyone else):

Concern	With wasm_js	Without
Clock	web-time (Performance.now)	time_compat::host_clock, embedder symbol
Timers (sleep, timeout)	gloo-timers (setTimeout)	spin on the host clock
Entropy	getrandom/wasm_js	getrandom custom backend
chrono::Utc::now	chrono/wasmbind (JS Date)	time_compat::now_utc

The host boundary is two functions, and the build script asserts the guest
imports nothing else:

interface host {
    now-micros: func() -> u64;
    random-bytes: func(len: u32) -> list<u8>;
}

Two real bugs fell out of this. history and touch's two-digit-year path
called chrono::Utc::now() directly, which reads std::time::SystemTime and
panics on wasm32-unknown-unknown. The existing time_compat scan test only
guarded std::time; it now guards chrono's clock too, which is what found
them.

Why

Asked whether bashkit could run inside Hyperlight. It can — the sandbox model
lines up almost exactly (Hyperlight guests have "no kernel or OS in the VM",
which is the environment bashkit already targets). The blockers were all
JS assumptions baked into wasm32-unknown-unknown, and they fail in the worst
possible way: an unresolved __wbg_* import at instantiation time, naming no
dependency.

Before / After

Before — the guest could not be built at all; a wasm_js-off build pulled in JS:

$ wasm-tools print bashkit_hyperlight_guest.wasm | grep '(import'
  (import "__wbindgen_placeholder__" "__wbg_performance_3fcf6e32a7e1ed0a" ...)
  (import "__wbindgen_placeholder__" "__wbg_setTimeout_56bcdccbad22fd44" ...)
  (import "__wbindgen_placeholder__" "__wbg_getTime_63fb0332e6c4ec17" ...)
  ... 21 imports, all JS

After:

$ ./examples/hyperlight/build-and-run.sh
==> guest imports (must be host-only)
(import "bashkit:sandbox/host"
==> running under wasmtime
beta gamma alpha        # VFS + sort | awk | tr pipeline
6                       # jq
slept 1s                # host clock import + spin timer
==> OK

And the component AOT-compiles for the actual micro-VM guest target:

$ hyperlight-wasm-aot compile --component target/bashkit-sandbox.component.wasm
Aot Compiling ... to [x86_64-unknown-none] (LTS wasmtime)

Sizes: 7.2 MB core module → 6.9 MB component → 22 MB .aot.

Not verified: booting an actual micro-VM. That needs /dev/kvm or Windows
WHP, which the dev container does not have. Recorded as the open tier in
knowledge/runtimes/non-js-wasm.md.

No behavior change for existing consumers: the JS packages enable wasm_js and
resolve to exactly the dependencies they used before.

Risk

• Low / Medium
• The wasm_js split is the risk surface. If a JS-backed dependency were missed,
  it breaks the non-JS build (new, covered by the added CI job), not the JS
  one — bashkit-wasm and the wasm CI check both enable the feature and compile
  the same code as before.
• chrono's wasmbind is now off outside the JS packages. Any new
  Utc::now() call is a lurking wasm panic, which the extended scan test now
  fails on.

Checklist

• Tests added or updated — extended the time_compat scan test to chrono's
  clock (caught the two bugs above), added now_utc tests, and a
  WASM component (no JS, no WASI) CI job that builds the component,
  asserts its import list, and runs a script through it under wasmtime
• Backward compatibility considered — internal code; JS packages opt into
  wasm_js and are unchanged

Local runs: cargo fmt --all --check, cargo clippy --workspace --all-targets --features http_client,ssh,sqlite -- -D warnings, the CI test slice (5191
passed), both wasm target checks, and the component smoke script. One unrelated
failure: ssh_supabase_connects times out because this sandbox has no outbound
SSH — it exercises a live public endpoint and runs in the ssh CI job.

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	537307f	Commit Preview URL Branch Preview URL	Aug 19 2026, 06:00 AM

[chaliy]

Deep review. Read the full diff (27 files), traced the wasm_js feature graph, the time_compat shim on all four target configurations, the WIT boundary, and the new CI guard. All 43 checks green, branch is a clean fast-forward on 986bfc7 (latest main).

The design holds up. Making web-time / gloo-timers / send_wrapper / getrandom/wasm_js / chrono/wasmbind all optional behind one wasm_js feature is the right seam — wasm32-unknown-unknown was never a proxy for "JS host", and the failure mode it produced (unresolved __wbg_* at instantiation, naming no dependency) is exactly the kind that needs a compile-time gate rather than docs. Dropping chrono's default features so wasmbind can't sneak back in, and extending the time_compat scan test to Utc::now()/Local::now(), closes the loop: the guard is what found the history and touch bugs, so the test is carrying real weight rather than restating the invariant. The wasm-component CI job is the part that keeps this from rotting — a stray JS-backed dep surfaces nowhere else.

Two findings, both minor and both scoped to the new non-JS target. Neither blocks.

1. host_clock::SystemTime cannot represent pre-epoch instants; touch silently clamps.

host_clock::SystemTime wraps an unsigned Duration, and Sub<Duration> saturates:

fn sub(self, rhs: Duration) -> SystemTime {
    SystemTime(self.0.saturating_sub(rhs))
}

So from_chrono of any pre-1970 datetime returns UNIX_EPOCH instead of a point before it. That path is reachable from user input: parse_touch_timestamp (fileops.rs:503) maps the 10-digit form with yy >= 69 to 1900 + yy, so touch -t 6912312359 asks for 1969-12-31, and the 12-digit form takes any year outright (touch -t 195001010000).

• native / WASI / wasm_js: std::time::SystemTime and web_time::SystemTime both represent pre-epoch, and the mtime round-trips.
• wasm_js off: mtime becomes 1970-01-01, no error.

The round_trip_pre_epoch_subsecond test proves the to_chrono_utc/from_chrono decomposition is right, but it only ever runs against std::time::SystemTime on the host — nothing exercises the host_clock types, so this is invisible to the suite. Narrow enough to accept knowingly; worth either a signed representation, or a line in knowledge/runtimes/non-js-wasm.md recording it as a known divergence of the wasm_js-off build.

2. The WIT comment understates the now-micros contract.

wit/bashkit.wit:

// Microseconds since an arbitrary but monotonic epoch. Used for shell
// deadlines and for the wall clock (`date`, file mtimes).

"Arbitrary but monotonic epoch" and "wall clock" are contradictory, and the second one is the binding constraint — host_clock feeds this straight into SystemTime, so date and mtimes are wrong by exactly the epoch offset if an embedder takes the first clause at its word. host_clock.rs states it correctly ("Microseconds since the Unix epoch, assumed non-decreasing"), and the host impl uses UNIX_EPOCH. Since the WIT is the file an embedder reads first, it should say Unix epoch and note the doubles-as-monotonic caveat that host_clock.rs already spells out.

Not blocking, no action needed: cargo install wasm-tools --version 1.256.0 --locked in the new job builds from source and isn't covered by rust-cache, so it adds a few minutes per run — fine now, a candidate for a prebuilt binary if the job gets noisy.

Holding off on merging: this isn't in one of the queues my scheduled run is authorized to ship from (issue-derived PRs, aardvark-labelled PRs, dependabot PRs), and it carries no reviews yet. Flagging it as ready from my side.

---

Generated by Claude Code

[JaggerJo]

This is really interesting!

I've seen a bunch of people "port" bashkit to their language of choice so it can be embedded without external dependencies. Having a WASM build that can be simply embedded using Wasmtime in e.g. .NET makes this directly available. Nice!