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

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

[vercel]

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:

• Risk-avoiding continuous mode #789
• add mode for python execution #3713
• Command pre- and post-processing to increase efficiency and efficacy #4045
• encourage people to use a separate user account w/o VM/docker #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