Rescriptum

Approvals & tool trust

How to configure permissions, enable auto-approve, and use the Journal trust progression.

Rescriptum provides fine-grained control over how much autonomy your agent is granted. You decide the blast radius.

Permission Presets

You can switch between three built-in permission presets via the shield icon in the chat header:

  • **Strict**: Every file edit, patch, and shell command requires explicit human confirmation. Recommended when exploring sensitive production code or untrusted scripts.
  • **Balanced (Default)**: Read-only operations (read_file, smart_read, read_symbol, search_files, get_diagnostics) execute automatically. File mutations and shell commands present approval cards with diff previews.
  • **Permissive**: All workspace-confined tools execute automatically without prompting. Shell commands outside the workspace or matching hard-deny rules still trigger approval cards.

Enabling Auto-Approve for Specific Tools

In the chat settings or tool prompt card, you can toggle **Always allow for this session** on individual tools (e.g. auto-approve patch_file and get_diagnostics, but keep manual confirmation for run_command).

The Tool Trust Journal System

Rescriptum includes a persistent **Journal** in src/intelligence/journal.rs. Every time a tool is executed, the system records:

  • Tool name and arguments
  • Exit status (success vs error)
  • Post-execution verification score

As a tool consistently succeeds in a workspace without causing rollbacks, the Journal builds a mathematical **Trust Score**. Tools that exceed the trust threshold are gradually promoted to auto-approval, reducing repetitive confirmation clicks as the agent proves its reliability.

Hard-Deny Safety Invariants

Regardless of permission settings or trust scores, certain operations are **permanently blocked** by Rescriptum's native command policy:

  • Destructive root filesystem commands (rm -rf /, del /s /q C:\)
  • Network exfiltration attempts on sensitive environment files (.env, id_rsa)
  • Modifying files outside the active project root without explicit workspace boundary elevation.