safe-bash: provide virtual /dev/null semantics for injected filesystems

[kamilio]

Safe-bash should provide /dev/null semantics across arbitrary injected filesystems, rather than requiring each product adapter to rediscover them.

Our persistent agent filesystem stores every supplied path as ordinary data. A model ran a missing command with 2>/dev/null; safe-bash forwarded that destination to storage, leaving a real 39-byte /dev/null file containing shell: line 3: find: command not found\n. Later ls -l /dev/null; cat /dev/null displayed the file and old diagnostic. This is a real product reproduction, not an expectation that the host OS null device is available.

Published-artifact audit: safe-bash/safe-fs 0.1.496 exports have no virtual-device filesystem helper; /dev/null occurrences in safe-bash concern diff/patch filename conventions, not general filesystem I/O. We currently intercept the canonical path in our adapter, but this is generic shell behavior that belongs upstream.

Please add a bounded device overlay (in safe-fs if that is the right abstraction), installed by safe-bash around an injected filesystem, with consistent behavior for redirection and command filesystem access (cat, stat, cp, tee, etc.):

• /dev/null always exists; reads return EOF, normal and append writes discard all bytes without persistence or whole-input buffering. Streaming drains respect cancellation and close the producer.
• Canonical absolute/relative paths resolve consistently. Exclusive creation fails EEXIST; device-as-directory/descendant access fails ENOTDIR; unlink/rename/replacement cannot turn the reserved device into an ordinary file.
• Define stat and directory-listing behavior (including /dev), and how the device is represented if FileStat currently only supports file/directory/symlink.
• Never forward null-device mutations to the backing store, consume its file quota, or delete an existing historical backing row. Any masked historical record remains the application's explicit cleanup responsibility.
• Public supported API only; exercise an injected persistent adapter and actual workerd, including a large canceled stream and a backing-store spy proving no persistent writes.

A redirection-only special case is insufficient: normal commands also invoke the filesystem directly. Product prompt listings may bypass the shell; our application must still hide historical /dev/null rows there until deliberately cleaned up. We will retain our temporary local behavior until a published upstream implementation is verified.

[kamilio]

Validated against the current delivered product using its public installed-artifact APIs, not just source inspection. An injected filesystem write-spy confirms that missing-command stderr redirection writes a real /dev/null backing row; subsequent cat exposes it, canonical /dev/./null also writes it, rm deletes it, and a fresh filesystem reports ENOENT instead of EOF. The tested artifact was the explicit 0.0.0-issue672-delivery3 candidate whose product tree matched delivered fd9ba58, not a claim of independently reproducing npm 0.1.496. This confirms the root issue remains after #669/#672. A redirection-only special case is insufficient; the shared filesystem boundary must cover commands, overrides, masking, metadata, reserved-path mutations and bounded stream cleanup. No fix is claimed yet; persistent-service and actual workerd acceptance will be required for the implementation.

[kamilio]

The reproduction is now independently confirmed with actual workerd and persistent storage, not only MemoryFileSystem. Three fresh Miniflare/container instances shared an owned persisted R2 store with no Node compatibility flags: a 32-byte historical /dev/null row survived the first recreation; the unfixed public installed artifact exposed it and replaced it with a 45-byte missing-command diagnostic; that corruption survived the next recreation. Ordinary-file persistence was verified separately, and backing calls/ETags/metadata were recorded. This tested the explicit 0.0.0-issue673-local candidate, not a claim of independently refetching npm 0.1.501. The shared device view and Shell integration are being implemented with character-device metadata and bounded cleanup. Final acceptance will rerun persistence, mutation-spy, large cancellation, and public-artifact checks against a fresh built candidate; no fix or new release is claimed yet.

[kamilio]

Implemented and verified on main in 6f32f86. Public SafeFS device overlay now protects /dev/null across injected filesystems, Shell overrides, mixed mounts and supported aliases without modifying historical backing data. Local complete uncached npm test, repository lint, normal build, packed CLI and installed package checks pass. Expanded actual-workerd acceptance passes all 43 groups, including persistent R2 recreation and bounded canceled streams. Closing immediately after verified remote-main delivery as requested; GitHub publication is being monitored separately and is not yet claimed complete.

[kamilio]

Publication verified: @poe-platform/safe-fs, @poe-platform/safe-bash, and @poe-platform/safe-js 0.1.502 are now on npm. Release workflow 34296926937 succeeded for main commit 6f32f86. Fresh installations of the published packages pass the maintained Node and Bun consumer checks. The device API is therefore available in the published scoped packages, not only local source. Historical backing rows remain untouched and application-owned cleanup/listing behavior still applies. The separate poe-code CLI release is still completing its required unit gate; it is not yet claimed published.

[kamilio]

Final delivery verified: poe-code@14.0.95 is now npm latest, with gitHead 6f32f86. GitHub release v14.0.95 was published September 9, 2026 at 01:15:42 UTC. Root release workflow 34296927108 completed successfully, as did scoped-package workflow 34296926937 for SafeFS/SafeBash/SafeJS 0.1.502. Local commits, remote-main delivery, and both GitHub publications are now independently verified.