Skip to content

Design: sandboxed build/elaboration ability for review agents #92

Description

@kim-em

Review agents are currently read-only (Read/Grep/Glob; reviewers.py pins this), per SECURITY.md's threat model: PR content is attacker-controlled, and an injected reviewer should have nothing worth doing. This issue is for designing a safe way to give reviewers elaboration ability, because some checks genuinely need it.

Motivating case: a merged PR carried a Module.Finite instance argument that is unused in the definition body but looks load-bearing (a statement-level letI consumed it downstream). The generality rubric's 'visibly unused' test cannot catch this without deleting the assumption and re-elaborating, and there is no mechanical fallback: Batteries' unusedArguments linter deliberately skips instance-implicit binders.

Constraints from the existing threat model:

  • Elaborating PR code is arbitrary code execution (build-time #eval, macros, initialize), which is why the TauCeti build runs under landrun in a trusted pull_request_target workflow.
  • A reviewer with bash/edit inside its own environment exposes its provider key (SECURITY.md R6) and could fabricate evidence for its verdict.

Plausible directions: run reviewer build experiments inside the same landrun sandbox profile the CI build uses, with the provider key held outside it (auth proxy, cf. issue #22); or expose a narrow 'elaborate this patched file' service to the reviewer rather than general bash.

🤖 Prepared with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions