feature request: git-based guardrails around filesystem changes

[matwerber1]

Is your feature request related to a problem? Please describe.

Started experimenting with Open Interpreter (very cool!), had some feature request ideas.

Overview

I'd be comfortable with, and even prefer, using auto_run if I was able to specify guardrails that could enforce (upper limits) on actions taken by the interpreter.

Describe the solution you'd like

Some example guardrails:

• Reliably limiting file change operations to a given directory
• Only allowing file changes to directories tracked locally by git
• If a file change would occur in a non-git directory, pausing to ask the user if I'd like Open Interpreter to first git init the current directory
• For git directories, an option to enable something like "auto-commit changes".
  • if auto-commit is enabled, allow me to configure options such as:
    • whether the current branch (whatever it may be) should be used for commits
    • whether commits are only allowed to branches with a certain customizable prefix, e.g. <my_username/interpreter/<name of feature>
    • specify a branch 'deny list' that prevents changes to branches with certain names, e.g. main, or prod

Ideally, these settings could be configured at different scopes, e.g.:

• applied to any interpreter session
• applied to any interpreter session that affects / takes place in a particular directory

I'd want to control these settings using YAML config files and, for convenience, maybe adjust or bootstrap a config file with the CLI.

Describe alternatives you've considered

Alternative ideas might include:

1. Prompt engineering - e.g. including a message in my initial prompt explaining the git-related rules I want interpreter to follow and consider before every command. While helpful, I still wouldn't feel comfortable relying on this due to inherit nature of LLMs (e.g. quality of model, size of context window, how well I word my instructions, the chance of hallucination in an executed command that is (always?) a possibility, etc.)

2. Custom instructions - same as above, except that the instructions would be included via Open Interpreter's custom instructions rather than the user typing them out at the beginning of each session. Same concerns with this approach as above.

3. Filesystem guardrails via a container - one way of solving similar goal of carefully limiting blast radius of filesystem changes without necessarily being tied to a git-based solution would be, if possible, running Open Interpreter in a Docker container and in a way conceptually very similar to MSFT DevContainers. With this approach, we could decide between (1) copying directories (changes won't be reflected in host OS) vs. mounting directories (changes reflected in host filesystem).

   • Edit - as I type this out, I double-checked docs and saw there is experimental Docker support. Still leaving in this example just for completeness' sake.

Additional context

No response