Scratch mount: persisted scratch space for sandboxed agents
Problem
A sandboxed agent has no clean way to hand artifacts back to the user. ~ is a tmpfs and dies with the session; the only RW paths to the host are the project dir (cluttering it with throwaway files and forcing gitignore noise) and agent config dirs (cursed — conflates agent state with scratch).
Concrete case that motivated this: asking the agent to draft a long markdown document (e.g., an issue body, a plan, a code-review summary) for the user to copy. Today the only options are scrollback or polluting the repo.
--mount-rw PATH can technically cover this, but it requires the user to pre-create a dir and remember to mount it. The point of a dedicated --scratch is "give me a known place to dump things, you handle the rest."
Proposed shape
- Flag:
--scratch [DIR]. With no argument, use a default host path (e.g. ~/.local/share/agentpen/scratch/<run-id>/). With an explicit path, bind that.
- Mount point inside sandbox: known constant, e.g.
~/scratch or /scratch. Settable via env var (AGENTPEN_SCRATCH) so the agent can find it without being told.
- Permission: RW from the sandbox.
- Lifecycle: dir is created if missing; not auto-cleaned on exit. User decides when to discard.
- Discoverability: print the host path on session exit if anything was written, so the user isn't left guessing where their artifacts went.
Out of scope (rejected alternatives)
- Stdout-export mode (
--export FILE capturing one final blob from a designated FD). Simpler but only handles single-shot output; doesn't help iterative scratch.
- Clipboard channel (sandbox shim → host helper →
xclip/wl-copy/pbcopy). Most ergonomic for "copy this for me," but it's a host-controlled side channel that needs careful bounding and is OS-specific. Possible follow-up if --scratch proves insufficient; not the first move.
- Letting the sandbox invoke arbitrary host commands (e.g.
gh issue create). Approximately equivalent to "no sandbox" — turns external-service inputs into uncapped exfiltration channels.
Threat-model notes
- Scratch contents are sandbox-written and must be treated as untrusted by the host. Don't blindly
source shell scripts from ~/.local/share/agentpen/scratch/, don't auto-execute anything in there, etc. Worth a one-liner in the README.
- For
paranoid (see paranoid-mode issue), --scratch is still useful — paranoid kills agent config persistence, not user-explicit artifact handoff. But the same untrusted-content caveat applies more strongly there.
Related
fs.go:82-85 — current $HOME-as-tmpfs setupmain.go:66-67 — existing --mount / --mount-rw flags this builds on- Paranoid profile issue —
--scratch should work the same in both profiles
Scratch mount: persisted scratch space for sandboxed agents
Problem
A sandboxed agent has no clean way to hand artifacts back to the user.
~is a tmpfs and dies with the session; the only RW paths to the host are the project dir (cluttering it with throwaway files and forcing gitignore noise) and agent config dirs (cursed — conflates agent state with scratch).Concrete case that motivated this: asking the agent to draft a long markdown document (e.g., an issue body, a plan, a code-review summary) for the user to copy. Today the only options are scrollback or polluting the repo.
--mount-rw PATHcan technically cover this, but it requires the user to pre-create a dir and remember to mount it. The point of a dedicated--scratchis "give me a known place to dump things, you handle the rest."Proposed shape
--scratch [DIR]. With no argument, use a default host path (e.g.~/.local/share/agentpen/scratch/<run-id>/). With an explicit path, bind that.~/scratchor/scratch. Settable via env var (AGENTPEN_SCRATCH) so the agent can find it without being told.Out of scope (rejected alternatives)
--export FILEcapturing one final blob from a designated FD). Simpler but only handles single-shot output; doesn't help iterative scratch.xclip/wl-copy/pbcopy). Most ergonomic for "copy this for me," but it's a host-controlled side channel that needs careful bounding and is OS-specific. Possible follow-up if--scratchproves insufficient; not the first move.gh issue create). Approximately equivalent to "no sandbox" — turns external-service inputs into uncapped exfiltration channels.Threat-model notes
sourceshell scripts from~/.local/share/agentpen/scratch/, don't auto-execute anything in there, etc. Worth a one-liner in the README.paranoid(see paranoid-mode issue),--scratchis still useful — paranoid kills agent config persistence, not user-explicit artifact handoff. But the same untrusted-content caveat applies more strongly there.Related
fs.go:82-85— current $HOME-as-tmpfs setupmain.go:66-67— existing--mount/--mount-rwflags this builds on--scratchshould work the same in both profiles