PaperClipAI/packages/plugins/sandbox-providers/daytona/DIRECTORY-CONSTRAINT-FINDINGS.md

Directory-constraint (bwrap) findings for the Daytona session path

Summary

The Daytona provider ran an advisory bubblewrap (bwrap) wrapper around each user command. The wrapper gave an agent real-time feedback when the agent wrote to a directory that the ephemeral sandbox does not keep. The wrapper was advisory only. It added no security boundary; the ephemeral sandbox is the only boundary.

The provider now runs each user command plain, both on the persistent-session path and on the one-shot fallback path. This note records why the provider drops the directory-constraint goal for now, and what a future re-introduction needs.

Why the goal is dropped for now

The session model runs one persistent shell per lease and feeds every command into that shell. The plan aimed to enter the bwrap sandbox one time per session and amortize its cost across every command in the session. A live validation proved this aim is not reachable with the current Daytona session daemon.

• An exec-replace of the session shell with bwrap stops the session from running any later command. A side-channel file proved the inner shell never ran the next command. A repeat without --new-session gave the same result, so --new-session is not the cause. The exec-replace itself breaks the session daemon's per-command delivery.
• A per-command bwrap wrap works inside a session (separated stdout and stderr, correct exit codes, the session stays alive), but it costs about 1.75 s per command. An un-wrapped session command takes about 0.29 s; a bwrap-wrapped session command takes about 2.05 s. The wrap adds the full cost back on every command, which removes the session model's speed win.

The wrapper was advisory, not a security boundary. The provider already ran a command plain when the bwrap capability probe failed, so the plain path is an accepted, shipped behavior. Dropping the wrapper drops only the advisory feedback; it does not change the command's privilege or isolation. The command runs as the unprivileged sandbox user (daytona) in both cases.

Removal scope

• The session dispatch runs the plain login-shell script, wrapped in a subshell so a top-level exit cannot end the persistent session shell.
• The one-shot fallback (used when the session model is off) also runs the plain login-shell script.
• The provider removed the per-command bwrap apply, the bwrap capability probe, the bwrap command builder, and the bwrapAvailable / sandboxUsername lease metadata that only the removed path used.
• The provider keeps the advisory writable-directory set, which a sync operation records from each access: "rw" mapping. Nothing reads the set today. It stays in place so a future isolation wrapper can consume it without a new sync change.

What a future re-introduction needs

• A persistent-namespace approach needs its own spike. Two candidates are:
  • Enter one namespace per session and route each command into it with nsenter.
  • Feed each command to the namespace shell through a FIFO instead of an exec-replace.
• Both candidates need a live test against the Daytona session daemon, because the exec-replace model is proven unreachable and the per-command wrap is too slow.
• The re-introduction must keep the session speed win. It must not pay the full bwrap setup cost on every command.
• The writable-directory set is already tracked per lease, so a new wrapper can bind those directories read-write without a sync change.
• The wrapper stays advisory. It must not become a security boundary; the ephemeral sandbox stays the only boundary.