WASM shell tools cannot read VFS files, including files created by the shell itself

[alanpog]

Title: WASM shell tools cannot read files from agentOS VFS, including files created by the shell itself

Summary

Using @rivet-dev/agent-os-core with @rivet-dev/agent-os-common, WASM shell tools like cat, grep, and sha256sum fail with Permission denied when reading:

• files written via vm.writeFile(...), and
• files created by the WASM shell itself.

This reproduces without Pi, LLM credentials, or any app-specific code.

Repro

Standalone repro gist:

• https://gist.github.com/alanpog/973d71c56d11dd43277f67753aea4319

Files in the gist:

• package.json
• repro.mjs

Package versions:

• @rivet-dev/agent-os-core@0.1.1
• @rivet-dev/agent-os-common@0.0.260331072558

Run:

npm install
npm run repro

Node version used locally:

v24.14.1 (linux x64)

Expected

• cat, grep, and sha256sum should be able to read files in the VM filesystem.
• This should work both for host-written files (vm.writeFile) and shell-created files.

Actual

All of these return nonzero with Permission denied, for example:

WARN could not retrieve pid for child process
grep: /mnt/scratch/input/host-written.txt: Permission denied (os error 2)
WARN could not retrieve pid for child process
cat: /tmp/wasm-shell-cat.txt: Permission denied
WARN could not retrieve pid for child process
sha256sum: /tmp/wasm-shell-sha.txt: Permission denied

The file metadata appears normal from the host API. For the host-written file, vm.stat() returned:

{
  "mode": 33188,
  "size": 36,
  "isDirectory": false,
  "isSymbolicLink": false,
  "atimeMs": 1775333947328,
  "mtimeMs": 1775333947328,
  "ctimeMs": 1775333947328,
  "birthtimeMs": 1775333947328,
  "ino": 3,
  "nlink": 1,
  "uid": 0,
  "gid": 0
}

mode: 33188 is 0100644, so the host API sees a normal world-readable file.

Notes

• AgentOs.create() appears to default host kernel permissions to allowAll.
• The failure also reproduces via direct vm.exec(...), outside agent sessions.
• Every vm.exec() call emits WARN could not retrieve pid for child process on stderr before any command output. This may be a related symptom or diagnostic clue.
• There is an errno inconsistency in the failures: grep reports Permission denied (os error 2) where os error 2 is ENOENT, while cat and sha256sum report plain Permission denied. That may help narrow down whether this is happening in the WASI/VFS layer.
• This makes it look like a VFS/WASM-shell integration bug or limitation rather than session approval config.

Question

Is there a missing filesystem permission or mount configuration needed for WASM commands to read VFS files, or is this a bug?

[alanpog]

I tested the equivalent of PR #1431 locally against the published @rivet-dev/agent-os-posix runtime and reran the standalone repro.

Result:

• ls /mnt/scratch/input now works
• find /mnt/scratch/input -type f now works
• cat /mnt/scratch/input/host-written.txt still fails with Permission denied
• grep "nebula-needle" /mnt/scratch/input/host-written.txt still fails with Permission denied (os error 2)
• sha256sum /mnt/scratch/input/host-written.txt still fails with Permission denied
• the same file-read failures still reproduce for files created by the shell itself in /tmp

So PR #1431 appears to fix directory reads / opendir()-style access, but not regular file reads.

I also still see WARN could not retrieve pid for child process on each vm.exec() call.

That narrows this issue from "WASM tools cannot access the FS at all" to something more like "directory access is fixed by #1431, but file reads still fail after that patch".

[alanpog]

I dug a bit further into the released vs current-main state.

This issue is still valid for released consumers today because @rivet-dev/agent-os-core@0.1.1 exact-pins @rivet-dev/agent-os-posix@0.1.0, and that published posix@0.1.0 still reproduces the standalone failure here.

What I found:

• published @rivet-dev/agent-os-posix@0.1.1 already contains the file-open flag mapping fix
• current main also already has that file-open mapping fix
• #1431 appears to fix the remaining upstream issue

So to resolve this for released consumers, it looks like:

1. merge #1431
2. publish releases so consumers stop resolving to @rivet-dev/agent-os-posix@0.1.0

Happy to re-run the standalone repro once new packages are published.

[NathanFlurry]

Thanks! Apologies for the slow response, catching up on support. Will confirm this is fixed as part of 0.2.0