pydantic/monty · error · Error

the wasm worker does not support filesystem mounts (browser

Error message

the wasm worker does not support filesystem mounts (browser has no host filesystem)

What it means

The wasm worker runs inside a browser Web Worker (or an in-process degrade) where there is no host filesystem, so `feedRun`/`feed` cannot honor `MountDir` mounts. If the request includes any mounts, the transport throws immediately rather than silently dropping them. Mounts are only available on the native napi/subprocess path.

Source

Thrown at crates/monty-js/ts/worker/transport.ts:134

            : { printFlushIntervalMs: flushIntervalMs(config.printFlushInterval) }),
        },
      },
      'ok',
      'Configure',
    )
    return transport
  }

  /** Feeds one snippet and eagerly converts its named inputs. */
  feed(
    code: string,
    inputs: Record<string, unknown> | null,
    mounts: readonly unknown[],
    options: { cwd?: string; skipTypeCheck: boolean },
    onPrint: OnPrint,
  ): Promise<NativeTurn> {
    if (mounts.length > 0) {
      throw new Error('the wasm worker does not support filesystem mounts (browser has no host filesystem)')
    }
    const cwd = feedCwd(options.cwd)
    if (typeof cwd !== 'string') {
      return Promise.resolve(cwd)
    }
    return this.turn(
      {
        tag: 'feed',
        val: {
          code,
          inputs: Object.entries(inputs ?? {}).map(([name, value]) => ({ name, value: encodeValue(value) })),
          skipTypeCheck: options.skipTypeCheck,
          cwd,
        },
      },
      onPrint,
    )
  }

View on GitHub (pinned to adc986b362)

Solutions

1. Remove the `mounts` argument (pass an empty array) when targeting the wasm worker.
2. Move file-dependent work to the host: read files in JS before the run and inject their contents via `inputs` instead of mounting directories.
3. If filesystem mounts are required, use the native napi pool (`Monty.create()` from the package root) which runs workers via the `monty` binary with a real `MountTable`.
4. Branch on environment capability at startup and choose the native vs wasm pool accordingly.

Example fix

// before
const session = await pool.checkout()
await session.feedRun(code, { mounts: [new MountDir('/data', './data')] }) // throws on wasm

// after
const session = await pool.checkout()
const data = await readFileText('./data/input.txt') // host-side read
await session.feedRun(code, { inputs: { data } })

if (mounts.length > 0 && isWasmPool(pool)) {
  throw new Error('strip mounts before feeding a wasm-backed session')
}

function supportsMounts(pool: WorkerPool): boolean {
  return !isWasmPool(pool) // native napi pools support MountDir
}

try {
  await session.feedRun(code, { mounts })
} catch (err) {
  if (err instanceof Error && err.message.includes('does not support filesystem mounts')) {
    await session.feedRun(code, { inputs: await readHostFiles() })
  } else throw err
}

When it happens

Trigger: Calling `session.feedRun(code, { mounts: [...] })` (or `feed(...)`) with a non-empty `mounts` array on a session obtained from `createWorkerPool` / the wasm `Monty` entry point.

Common situations: Sharing one code path between native (`@pydantic/monty` napi) and browser deployments where the native path accepts mounts; porting server code that uses `MountDir` to the browser; forgetting that `@pydantic/monty/wasm` is the browser-targeted subpath.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Monty.create could not auto-load the monty wasm module in th
• Dump returned an unexpected event
• ${what} produced no turn-ending event (worker crashed)
• ${what} expected event ${kind}, got ${event.tag}
• MontyFileHandle path must be a string

AI-assisted analysis of pydantic/monty@adc986b362 (2026-09-13). Data as JSON: /api/errors/94a2513e26e1ab8b. Report an issue: GitHub.