Skip to content

agent: confine the run tool's commands to the project folder #204

Open

Description

@AojdevStudio

The agent's run tool (sidecar/src/agent.ts) runs uv in the project folder with a small environment, a timeout, and a guard that ends the command when its sidecar ends. The command still runs as the person, so Python it runs can read or write any file the person can. The project-folder check covers only the file tools (read, write, edit) and pictures sent with a message.

CodeRabbit raised this on #200 (discussion_r4502787316). It is out of scope there, since #200 moves the agent loop into the sidecar without changing what a command may reach.

It also bears on three of CodeRabbit's declined findings on #200: the time between a path check and its open in the file tools and for pictures, and the operation receipts kept in the project's .m3d/ops. Once commands are confined, those become worth hardening. Today a command can already do anything they would allow.

A likely approach on macOS: run the guard under a Seatbelt profile (sandbox-exec) that allows reads of the system, the uv cache, and the Python toolchains, and allows writes only in the project folder and a temp folder. Check first that uv's downloads and the Bambu-free build scripts still work under it.

Activity

  1. pullfrog commented on Nov 7, 2026

    @pullfrog

    No confirmed duplicate found. #192 concerns process cleanup, not filesystem confinement. This work builds on #200, where sidecar/src/agent.ts currently lives; it is not yet on main.

    Implementation plan

    1. Add an OS-enforced launcher at run’s env.exec boundary. Both the parent agent and Astra already share this tool, so keep one enforcement path. Preserve the guard, timeout, restricted environment, output logs, and durable replay behavior.
    2. Prototype macOS Seatbelt confinement around the guard and its descendants. Allow the resolved project and a private temporary directory to be writable; allow only required system/runtime reads, not broad access to HOME. Resolve uv, Python toolchain, and cache paths explicitly. Prefer a dedicated writable cache over making shared executable caches writable.
    3. Establish compatibility with uv downloads and the Bambu-free build/check scripts before adopting the profile. Sandbox setup failures must return an actionable error rather than silently executing unrestricted. Make support on other platforms explicit.
    4. Keep file-tool/image path races and .m3d/ops receipt integrity as separate hardening work. A writable project still exposes its receipts; filesystem confinement alone does not make those trusted.

    The optional verification-doctrine lookup failed with HTTP 404; no test execution or verification claims are made here. No code changed and no PR opened.

    Pullfrog  | Implement a fix ➔ | View workflow run | via Pullfrog | Using gpt-6.1-sol | 𝕏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions