@@ -861,7 +861,10 @@ jobs:
   test-custom-async-runtime-wasi:
     runs-on: ubuntu-latest
     name: Test custom async runtime on wasm32-wasip1
-    timeout-minutes: 10
+    # The last step builds this addon twice for wasm32-wasip1 — once
+    # `async-runtime`-only, once combined with `tokio_rt` — and the two feature
+    # sets share no cargo fingerprints, so the second is a full rebuild.
+    timeout-minutes: 15
     needs: audit
     steps:
       - uses: actions/checkout@v7
@@ -908,7 +911,8 @@ jobs:
         run: |
           yarn workspace @examples/napi test \
             __tests__/wasi-buffer-public-api.spec.ts \
-            __tests__/wasi-deferred-before-exit.spec.ts
+            __tests__/wasi-deferred-before-exit.spec.ts \
+            __tests__/wasi-env-cleanup-export.spec.ts
         env:
           NAPI_RS_TEST_THREADLESS_WASI_BUFFER: '1'
       - name: Test lifecycle public surface
@@ -926,6 +930,13 @@ jobs:
         run: yarn workspace @examples/custom-async-runtime test:workerd
       - name: Test examples/napi threadless public surfaces
         run: yarn workspace @examples/napi test:wasi-public-surfaces
+      # Last: this rebuilds custom_async_runtime.wasm32-wasip1.wasm in place. It
+      # is the only lane that loads the addon through a loader the test controls,
+      # which is what makes it able to drive `napi_prepare_wasm_env_cleanup` by
+      # hand and observe that the backend shut down while the environment was
+      # still alive.
+      - name: Test threadless WASI environment teardown barrier
+        run: yarn workspace @examples/custom-async-runtime test:wasi
 
   # Node-only lane: the threadless wasm32-wasip1 artifact built from the real
   # `napi-async-runtime` adapter driven by the real `@napi-rs/async-runtime`
 
@@ -50,10 +50,13 @@ if (dispose) {
 The symbol is present only when the loaded binding is WASI. Browser WASI
 loaders expose it on their default export. Disposal releases the instance: it
 destroys the emnapi context and then terminates the workers owned by that
-binding. Pending napi-rs runtime promises are settled or cancelled first only
-when the binary exports the `napi_prepare_wasm_env_cleanup` preparation hook
-(a planned napi-side follow-up); otherwise they may remain pending forever,
-so settle in-flight work before disposing. Concurrent calls share one
+binding. Before that, the loader calls the binary's
+`napi_prepare_wasm_env_cleanup` preparation hook, which shuts the addon's async
+runtime down while the environment can still call into JavaScript. A registered
+`AsyncRuntime` backend quiesces there and its cancelled tasks reject their
+promises; the built-in Tokio runtime only _starts_ draining, so with it a
+promise whose task is still running can still be left pending. Settle in-flight
+work before disposing if that matters. Concurrent calls share one
 promise, successful disposal is idempotent, and a failed cleanup phase can be
 retried by calling the same function again. Do not call addon exports after
 disposal completes.
 
@@ -2,7 +2,11 @@ import ava, { type ExecutionContext } from 'ava'
 import { parseSync } from 'oxc-parser'
 
 import { createCjsBinding, createEsmBinding } from '../templates/js-binding.js'
-import { createWasiBrowserBinding } from '../templates/load-wasi-template.js'
+import {
+  createWasiBinding,
+  createWasiBrowserBinding,
+  createWasiDeferredBrowserBinding,
+} from '../templates/load-wasi-template.js'
 import { createWasiBrowserWorkerBinding } from '../templates/wasi-worker-template.js'
 
 const test = ava
@@ -200,6 +204,86 @@ for (const { name, code } of cjsBindingCases) {
   })
 }
 
+// `napi_prepare_wasm_env_cleanup` only *queues* the promise settlements of the
+// tasks it cancels: `napi_call_threadsafe_function` appends to the
+// threadsafe-function queue, and @emnapi/core dispatches that queue from a
+// macrotask two coalescing turns later. `Context.destroy()` then drains the
+// queue with a null env and discards it. Measured against @emnapi/core
+// 2.0.0-alpha.3: zero microtask checkpoints ever deliver the settlement, and it
+// takes exactly two macrotask turns.
+//
+// So a loader that emits the barrier and `destroy()` back to back strands
+// exactly the promises the barrier exists to settle, and it does so silently.
+// `examples/custom-async-runtime` covers the hand-written loader and the two
+// emitted flavors it builds (node cjs threadless, deferred/workerd)
+// behaviorally; the other flavors are never instantiated by any test, so assert
+// the shape here as well.
+const wasiLoaderCases: Array<{ name: string; code: string }> = [
+  { name: 'node cjs', code: createWasiBinding('test', '@scope/test') },
+  {
+    name: 'node cjs threadless',
+    code: createWasiBinding('test', '@scope/test', 4000, 65536, false),
+  },
+  { name: 'browser esm', code: createWasiBrowserBinding('test') },
+  { name: 'deferred/workerd', code: createWasiDeferredBrowserBinding('test') },
+]
+
+for (const { name, code } of wasiLoaderCases) {
+  test(`WASI loader waits for queued settlements before destroy: ${name}`, (t) => {
+    t.true(
+      code.includes('napi_prepare_wasm_env_cleanup'),
+      'loader must run the pre-teardown barrier',
+    )
+    t.true(
+      code.includes('napi_wasm_env_cleanup_pending'),
+      'loader must poll napi_wasm_env_cleanup_pending; without it the barrier queues settlements that Context.destroy() then discards',
+    )
+    t.true(
+      code.includes('__drainWasmEnvCleanup'),
+      'loader must call the settlement drain on its disposal path',
+    )
+    t.true(
+      code.includes('__scheduleMacrotask'),
+      'the drain must yield real macrotask turns; microtask checkpoints never let the emnapi dispatch run',
+    )
+    // Initialization rollback is the same hazard, one step earlier. Registration
+    // runs with a live environment, so a module-init hook can start a task and
+    // *then* return an error; the barrier cancels the task and queues its
+    // rejection, and a rollback that destroys the context in the same turn
+    // discards it — stranding a promise that already escaped into JavaScript.
+    t.true(
+      initializationRollbackBody(code).includes(
+        DRAIN_CALL_BY_ROLLBACK_FLAVOR[
+          code.includes(EAGER_ROLLBACK_SIGNATURE) ? 'eager' : 'deferred'
+        ],
+      ),
+      'initialization rollback must drain queued settlements before destroying the context',
+    )
+  })
+}
+
+const EAGER_ROLLBACK_SIGNATURE = 'function __rollbackWasiInitialization() {'
+const DEFERRED_ROLLBACK_SIGNATURE = "__lifecycleState = 'failed'"
+const DRAIN_CALL_BY_ROLLBACK_FLAVOR = {
+  eager: '__drainWasmEnvCleanup',
+  deferred: '__prepareForDisposal',
+} as const
+
+/**
+ * The body of a loader's initialization-failure path: `__rollbackWasiInitialization`
+ * for the eager loaders, `__createInstance`'s catch for the deferred one.
+ * Sliced rather than searched whole-file, so a drain that only runs on the
+ * ordinary disposal path cannot satisfy the assertion.
+ */
+function initializationRollbackBody(code: string): string {
+  const eagerStart = code.indexOf(EAGER_ROLLBACK_SIGNATURE)
+  if (eagerStart !== -1) {
+    return code.slice(eagerStart, code.indexOf('\n}', eagerStart))
+  }
+  const deferredStart = code.indexOf(DEFERRED_ROLLBACK_SIGNATURE)
+  return code.slice(deferredStart, code.indexOf('throw error', deferredStart))
+}
+
 test('createEsmBinding is Node 12 compatible', (t) => {
   const code = createEsmBinding('test', '@scope/test', ['sum'])
   assertValidJS(t, code, 'esm')