rivet-dev / rivet-dev/agentos

WasmVM brush-shell: `>>` append truncates and `< file` stdin redirection fails

Open
#1,657 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
4.6k
Forks
251
Avg merge
2d 15h
Merged PRs (30d)
34

Description

Summary

Two shell-redirection behaviors are broken in the WasmVM guest shell
(brush-shell), surfaced by the runtime-core integration suite:

  1. Append redirection (>>) truncates instead of appending.
  2. Stdin redirection (cmd < file) fails with a non-zero exit.

Both diverge from Linux/POSIX shell semantics.

Failing tests

packages/runtime-core/tests/integration/bridge-child-process.test.ts

Test Expected Actual
execSync append redirection onto a write-only file succeeds like Linux file contains originalchanged (append) changed — the >> truncated the file instead of appending
execSync stdin redirection feeds the kernel VFS file to the command cat < stdin-input.txt exits 0 with the file contents Error: Command failed: cat < stdin-input.txt, exit code 1

Exact assertion output:

× execSync append redirection onto a write-only file succeeds like Linux
  → expected 'changed' to be 'originalchanged' // Object.is equality

× execSync stdin redirection feeds the kernel VFS file to the command
  → stdout:
    Error: Command failed: cat < stdin-input.txt
    : expected 1 to be +0 // Object.is equality

Repro

# build/vendor the WASM commands, then:
pnpm --filter @rivet-dev/agentos-runtime-core exec vitest run \
  tests/integration/bridge-child-process.test.ts

The tests route child_process.execSync(...) through the bridge → kernel →
WasmVM sh (brush-shell), so the failures are in the guest shell's handling of
>> and <, not in the Node bridge.

Suspected root cause

  • >>: the append open-mode is not honored against the kernel VFS — the
    file is opened truncating (O_WRONLY|O_TRUNC) instead of appending
    (O_WRONLY|O_APPEND). Related patched area:
    toolchain/std-patches/crates/brush-* (WASI path/redirection support).
  • < file: input redirection from a VFS path is not wired to the command's
    stdin, so cat reads nothing and exits non-zero.

Not a regression

These predate and are unrelated to the registry→software flatten/colocation
refactor. Verified: the failing test file is unchanged, the vendored
runtime-core/commands binaries the test runs are unchanged, the brush-shell
source patches only moved (0 content delta), and the only runtime-core source
change is a moot commands-dir path string. The failures reproduce identically on
the parent revision.

Impact

Any guest program relying on >> append or < stdin redirection behaves
incorrectly (silent data loss on append; command failure on stdin redirect).

Related (separate issue)

The same integration run also has a WasmVM signal/dispose cluster — SIGKILL/
SIGTERM not terminating guest processes and dispose timing out
(signal-forwarding.test.ts, dispose-behavior.test.ts). Distinct root cause
(process signal delivery, not shell redirection); should be tracked separately.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running packages/runtime-core/tests/integration/bridge-child-process.test.ts with the provided pnpm command and inspect the failing append and stdin-redirection cases. Then read the related toolchain/std-patches/crates/brush-* area for WASI path and redirection support. Done means append preserves existing content and cat < stdin-input.txt exits successfully with the VFS file contents.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, shell, typescript, wasm
Domain
cli, operating-systems, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.