#1350 Extension runtime grants --allow-run but denies in-process Deno.open of a device node (blocks hardware I/O extensions)

What

An extension model method that opens a character device with Deno.open(path, { read: true, write: true }) fails at runtime, even though the same method can spawn subprocesses via Deno.Command. The error is the compiled-binary form:

Failed to open /dev/ttyUSB0: Requires all access to "/dev/ttyUSB0",
specify the required permissions during compilation using deno compile --allow-all

Why it's surprising

--allow-run is effectively granted (a stty Deno.Command in the same method runs fine), yet Deno.open on a device node is refused. allow-run is the strictly larger capability — a subprocess can do arbitrary I/O with no Deno sandbox at all — so denying an in-process device open while permitting subprocess spawning isn't a meaningful security boundary; it just blocks the straightforward implementation and pushes authors toward shelling out to dd/cat (which then bypasses Deno's fs capability model entirely).

Repro

1. Author an extension model whose method calls await Deno.open("/dev/ttyUSB0", { read: true, write: true }) (a serial device the OS user can access — group dialout).
2. swamp model method run <inst> <method>.
3. Observe the Requires all access … deno compile --allow-all failure. A Deno.Command("stty", …) earlier in the same method succeeds.

Environment

swamp 20260720.142822.0-sha.0caa5556, Linux, compiled binary. scripts/compile.ts lists --allow-read --allow-write --allow-run --allow-net --allow-sys --allow-env (unscoped), so the effective denial of a device-node read+write is unexpected.

Ask (either is fine)

• Grant extension execution the fs access implied by the compiled flags (so Deno.open on an accessible device works), or
• Document that extension fs I/O is constrained and that hardware/device extensions should use subprocess I/O — so authors don't discover this only at runtime.