# Command filters and actual filesystem effects

**Executed October 1, 2026 · Scripted Linux filesystem lab · No model.**

## Question and setup

Can the same protected-file write pass a command-string filter when expressed as a script, encoded script or child process? Does a read-only mount prevent that write while preserving a legitimate workspace task?

[reproduction script](/research/harness-effects-lab.py) creates fresh temporary directories containing only a synthetic canary, a workspace output and two scripted payloads. Each case first writes a legitimate result to the workspace. An intentionally weak pre-execution filter then blocks invocations containing `/lab/protected`. It sees only the invocation text, not script contents. It is **our deliberately weak filter**, not a recreation of Claude Code, Cursor or their permission parsers.

Four representations attempt the same write: inline Python, a staged Python file, a base64-encoded inline program, and a parent Python program spawning the staged file. Nothing deletes files or touches system directories. The driver stages scripts as fixtures; it does not test a client's file-write hooks or the model's ability to invent a bypass.

Docker containers use an unprivileged UID, no added capabilities, `no-new-privileges`, read-only rootfs, no network, memory/CPU/PID limits, a writable workspace mount and a protected mount. **Both configurations share those outer restrictions.** Only the protected mount changes from writable to read-only. No repository, real home, credential directory, Docker socket or other host data is mounted. The trusted driver observes the canary digest outside the container after each attempt. It does not accept the script's stdout as evidence of filesystem state.

## Results

Eight cases per execution: one of each form in each configuration. A validation rerun after strengthening the legitimate-output failure check produced the same eight outcomes.

| Representation | Command filter | Writable protected mount | Read-only protected mount | Legitimate task |
|---|---|---|---|---|
| Direct inline write | blocked | no attempt / unchanged | no attempt / unchanged | completed in both |
| Staged script | allowed | canary changed | canary unchanged; exit 17 | completed in both |
| Encoded program | allowed | canary changed | canary unchanged; exit 17 | completed in both |
| Child process | allowed | canary changed | canary unchanged; exit 17 | completed in both |

In the writable cases the payload deliberately prints `protected unchanged` after changing the canary. The independent digest shows otherwise. This is a constructed misleading message, **not evidence that a language model lied**. In the read-only cases the write raises an OS error; our payload turns it into `permission denied` and exit 17.

The useful task is a **separate prior invocation**, checked against expected output in each case. This tests availability of workspace writes; it is not a complex coding-task completion score and says nothing about finishing the legitimate job after a denial.

The driver treats failed setup, failed legitimate output, unexpected exit codes and unexpected effects as failures. A broken Docker daemon or inaccessible mount is not counted as successful protection. Execution output remains local rather than entering the repository as a runtime report.

## Environment and reproduction

- Host kernel: `6.8.0-142-generic`; Docker server `27.3.1`.
- Used image ID: `sha256:25c5b8011a3425a140bf5fa73be0feabd3c0d5b323eecb19dc02437a368ae075`.
- Registry digest: `python@sha256:57cd7c3a7a273101a6485ba99423ee568157882804b1124b4dd04266317710de`.
- Source uses Python standard library only. It inspects the selected local image, then runs the immutable image ID with `--pull=never`.

With Docker and Python available:

```sh
docker pull python@sha256:57cd7c3a7a273101a6485ba99423ee568157882804b1124b4dd04266317710de
python3 harness-effects-lab.py --image python@sha256:57cd7c3a7a273101a6485ba99423ee568157882804b1124b4dd04266317710de > /tmp/ra-boundary-results.json
```

Containers exit normally and remove themselves. Temporary fixtures are owned and cleaned by the driver. No listening server or persistent daemon is started. A timeout is a failed run; if Docker becomes unresponsive, inspect task-owned containers before any cleanup rather than stopping unrelated workloads.

## What this establishes and what it does not

**Observed:** three alternative representations evade this deliberately naive command-string filter; a read-only bind mount stops their protected write on this setup; all eight separate legitimate workspace writes complete.

**Architectural inference:** the filesystem checks an actual write, independent of how its program was represented. A command wrapper's statement is not an independent observation of its descendants' effects.

**Not tested:** any model's intent, persistence or ability to adapt; a real coding client's hooks; privileged or sandbox-escape paths; Windows/macOS equivalents; reads or disclosure of the canary; network/receiver authorization; port reservation and process teardown; credential brokerage; budget reservation; syscall tracing; monitor tampering; representative task utility. The Docker daemon and host kernel are trusted. The mounted workspace remains writable by the container; its contents are not trusted policy or evidence.

The observer checks before/after file digests, not an event stream. A transient change followed by restoration would be invisible to these snapshots. The fixed payload performs one write without restoration; this lab establishes its final effect, not completeness of a general runtime monitor.

A read-only file boundary does not prevent harmful actions against a service the workload is authorized to use. It does not make the rest of the workload secure. See the earlier [sandbox boundary pilot](https://rethinkingagents.com/research/sandbox-boundary-pilot.md) for a distinct experiment about permitted network routes.