fix/execute_code

[Jwdev-wr]

When not running in docker files should be executed using system python.

Background

Changes

Documentation

Test Plan

PR Quality Checklist

• [x] My pull request is atomic and focuses on a single change.
• [ ] I have thoroughly tested my changes with multiple different prompts.
• [x] I have considered potential risks and mitigations for my changes.
• [x] I have documented my changes clearly and comprehensively.
• [x] I have not snuck in any "extra" small tweaks changes

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
docs	⬜️ Ignored (Inspect)			May 6, 2023 5:18am

[Boostrix]

while that's a trivial change in theory, it's opening up a whole new can of worms. You will almost certainly want to make this optional by introducing a corresponding new env option to enable this. And if this is to be accepted, there should probably be some additional restrictions in place.

For instance, enabling Auto-GPT to execute code/scripts OUTSIDE of docker/chroot environments would be better supported only for a dedicated "autogpt" user - to isolate the user/admin (root!) account [home directory] from the script - which is basically a remote code execution engine primed by your prompts - but overall, it's just a fancy RCE-engine, so you really don't want to circumvent all sorts of security concerns here - things are inevitably going to go wrong at some point.

Then again, I do agree that the system is most useful if you grant it with access to executing scripts and command, but it would be better to introduce additional safety measures - so that people need at least to remove those explicitly.

See also:

• #789
• #3713
• https://github.com/Significant-Gravitas/Auto-GPT/issues/4045
• https://github.com/Significant-Gravitas/Auto-GPT/pull/3961

[k-boikov]

The idea is that when you run in docker you are in a sandbox so you can run python code safely. If you are not - then python code is executed in a docker sandbox. No bugs here.

[Boostrix]

I believe someone recently pointed out that there might be a confusing conceptual problem due to the disjoint between what the python sandbox is what other shell commands get to see/do (can't seem to find the comment currently)

[Jwdev-wr]

The idea is that when you run in docker you are in a sandbox so you can run python code safely. If you are not - then python code is executed in a docker sandbox. No bugs here.

The bug arises when a library outside of the docker image is required. Sandbox fails and agents can enter into loops trying to get it to execute. For example if it uses python3.9:alpine and attempt to use numpy.

Numpy is not a standard python library.

However, this solution isn't the best.

[Boostrix]

@valayDave summed up the issue pretty well when he pointed out how the agent gets to see very little surrounding/environmental state and is acting on weird assumptions, especially once commands cross multiple shell sessions or even machines (think ssh).

See: #4138