In the previous lesson, we played it safe with our permission system, we ran cloud in its native sandbox, auto allowing the best tool execution, requests falling out of the sandbox, fell back to the regular permission system which we can manage with an allow and a denial ist, and finally, we added hooks for a more fine-grained control, for example, when calling our dev tools mcp. In this lesson, we will remove the entire permission layer and we will try to do it safely.

In this lesson, we will remove the entire permission layer and we will try to do it safely. You probably know where I'm going with this, we'll be running the model in bypass permission mode. Let's take a look. To enable bypass permissions, we can do a few things. We can run cloud - dangerously skip permissions. And by doing this, we are running cloud in bypass permission mode, as you can see in the bottom left corner, and we can cycle through the modes by

mode, as you can see in the bottom left corner, and we can cycle through the modes by pressing shift tab. And by running cloud with a dangerously skip permissions flag, we get access to bypass permissions in this list. We can also just add this in our config, we can go to settings, and we can update the default mode instead of saying accept edits, we can say bypass permissions. And now, when we run cloud without a flag, we're still going to be in bypass permissions

permissions. And now, when we run cloud without a flag, we're still going to be in bypass permissions mode. First things first, we are still running in the sandbox, so the sandbox is still active, but now when a tool call falls outside of the sandbox, it will be auto-allowed. I highly recommend at least having the native sandbox active when running in bypass permissions mode on your machine. Because we're running in bypass permissions mode, the allow list is

mode on your machine. Because we're running in bypass permissions mode, the allow list is made redundant, so I removed it from the settings file, but the denial list is still respected. Let me show you. Let's ask the model to create a file called test. txt with a content, a hello world. And then let's ask it to delete this file. And this will fail because RM is in our denial list and we get this permission error. So this is the first important takeaway. In bypass permission mode, the denial list still

error. So this is the first important takeaway. In bypass permission mode, the denial list still gets respected and becomes even more important. On top of that, even while running in bypass permissions mode, the pre-tool use hook would still be fired and we can still intercept tool calls. And if you open up the logs file, we should see all the tool calls coming in, they will be allowed, so they will fall back to the regular permission system where the writing is allowed and the

allowed, so they will fall back to the regular permission system where the writing is allowed and the removal is denied. Next, let's write the following prompt. Let's say echo hello world and pipe the output to PRD test.txt. Because we're in the sandbox, you might expect this to fail because if you take a look at the deny write rule, we deny writing to the PRD directory. And initially, it'll fail. It'll say operation not permitted because we're in the sandbox

And initially, it'll fail. It'll say operation not permitted because we're in the sandbox and writing to the PRD directory is restricted. But if you say bypass the sandbox and try again, and this time it succeeded because it escaped the sandbox and there is no restriction in place outside of the sandbox. So let's open up the sandbox configuration. Let's go to overrides and we can see that allow un-sandboxed file back is enabled and we can actually disable it by

and we can see that allow un-sandboxed file back is enabled and we can actually disable it by saying strict sandbox mode. Because we're in strict sandbox mode, bypassing the sandbox is not allowed anymore. So even if you say bypass the sandbox, echo hello world and pipe the output to PRD test two dot txt, this will be denied. Because remember, sandboxes are enforced outside of cloud by the operating system itself. So no matter what, cloud cannot circumvent this restriction.

of cloud by the operating system itself. So no matter what, cloud cannot circumvent this restriction. But a big side note here is that only the best tool executions will be sand books. Other tool uses will not. All right, we've tightened our sandbox by disallowing the best tool to bypass the sandbox. So we're enforcing a strict sandbox. But there's still one major issue. Even in the sandbox, cloud has access to the entire machine and everything that's installed on it. For example,

sandbox, cloud has access to the entire machine and everything that's installed on it. For example, you may have the AWS CLI installed and cloud will happily execute commands using the CLI if we ask it to, for example, can you run the scribe regions with AWS. Because we're in the sandbox, we'll still get notified by network requests going outside, which in this case, we want to allow and execution continues. And here we can see the output. These network permission requests will

and execution continues. And here we can see the output. These network permission requests will keep happening even in bypass mode, which can become a bit annoying. So we're looking at two different issues here. Issue number one, we might be authenticated in the AWS CLI with admin privileges, and this can lead to disasters, which we don't want. And issue number two, network requests aren't automatically allowed, which is by design, but can become an issue in our rel floops.

aren't automatically allowed, which is by design, but can become an issue in our rel floops. My number one priority when running rel floops is peace of mind. I can't have it go rogue and delete my infrastructure via Terraform because I'm authenticated in the AWS CLI on this machine, which is actually my biggest nightmare scenario. In an ideal world, I want to tightly control the environment in which cloud is running, while basically giving it unrestricted access to this isolated environment. There are a few ways to achieve this, for

giving it unrestricted access to this isolated environment. There are a few ways to achieve this, for example, by using Docker Sandboxes. And this will essentially replace the native sandbox ing with an entire container the model has access to. The benefit here is that there's a good amount of separation between my physical machine, the host, and the container in which cloud has unrestricted access. To set up a sandbox, we can say Docker sandbox run cloud, it's going to pull

unrestricted access. To set up a sandbox, we can say Docker sandbox run cloud, it's going to pull the templates and after about a minute will be dropped into the cloud console. And after it starts, we need to authenticate again with our subscription or pass an API key, and you'll be charged by the token. So I quickly authenticated with my subscription. The reason we need to authent icate is because there is no sharing between the hosts and the container. So cloud cannot find

icate is because there is no sharing between the hosts and the container. So cloud cannot find its configuration files, and it'll be treated as a fresh install. Now, if you try to run AWS, we 'll see AWS command was found, even though it is installed on my host. But because we're running cloud in this isolated sandbox, it cannot access that binary Docker Sandboxes are a pretty interesting concept, because they use a very lightweight micro VM architecture. But unfortunately,

interesting concept, because they use a very lightweight micro VM architecture. But unfortunately, they're still highly experimental. And in my experience, not yet suitable for running relfl ups, a different project that is suitable is called Yolo box. Yolo box is essentially a regular Docker container that runs your coding agent, but with a few nice features that makes our life as developer easier. Let me show you. You start by installing the Yolo box using this brew

as developer easier. Let me show you. You start by installing the Yolo box using this brew install command, and after it's installed, we can run Yolo box cloud. The first time you run this, the Docker image will have to download, which only takes about a minute, but then we're good to go. The first thing we notice here is that we need to authenticate again, and this gets tiring pretty fast. Now, this makes sense because a Yolo box Docker container only mounts our

gets tiring pretty fast. Now, this makes sense because a Yolo box Docker container only mounts our project directory, not the home directory. So cloud does not find any of its configuration files and treats this as a fresh start. However, Yolo box has our back, we can say Yolo box, cloud dash dash, cloud config. Before we run this, let's also say dash, get config. And this will copy over the cloud configuration files and our git configuration files from the host into the container. And

the cloud configuration files and our git configuration files from the host into the container. And there we have it, cloud is now authenticated in the Yolo box container, and we forwarded or git configuration as well. Besides mounting our project directory, the Yolo box also has Git, we can say which Git. It also has the GitHub CLI, we can say which GH and let's say bash mode. And by default, there's also a node binary available for us, we can say which node. There we go

default, there's also a node binary available for us, we can say which node. There we go . And this means we can also run our off loops easily inside the Yolo box. Let's exit. And to do this, we just say Yolo box, we get dropped into a shell, and then we can say node Ralph.js. Running plot. And by extension, our off loops inside the Yolo box means we can safely remove the sandbox entry from our configuration file. Our Yolo box will essentially

safely remove the sandbox entry from our configuration file. Our Yolo box will essentially replace our native sandbox. Finally, Yolo box allows project level container customization with a simple config file. We can create a new file dot Yolo box dot tunnel, then we can say customize, then we can say packages, and let's say we're developing a Laravel app. So we need PHP 8.3. And now when we run Yolo box, the PHP 8.3 package will be installed for us as we can see here on screen. And

we run Yolo box, the PHP 8.3 package will be installed for us as we can see here on screen. And after it's installed, we can verify that PHP works with PHP PHP version, and it's going to be 8.3. That's great. We can also go a bit more advanced and we can create a Docker file fragment, but I verify myself using this. And instead I rely on the configuration file for customizing my containers. If you, for example, need to connect to a MySQL database, you can run Yolo box with -shot

containers. If you, for example, need to connect to a MySQL database, you can run Yolo box with -shot docker. And this will make sure that a Docker socket is mounted inside the container. So you and your agent get access to Docker inside the container. We can say Docker PS, and we can see the running containers. And this means you could simply ask Claude inside the Yolo box container to set up a MySQL container. And this could be shared across multiple Yolo box containers. So it's a very

MySQL container. And this could be shared across multiple Yolo box containers. So it's a very powerful feature. Finally, the coding agent also has root access. So you can literally just ask it to install all the packages you need. Definitely check out the README file of Yolo box, because there are a ton of configuration options in there for you to discover. Running or coding agent inside the Yolo box container means we effectively created a separation layer between our host

inside the Yolo box container means we effectively created a separation layer between our host machine and the container in which the coding agent is running. This means we can be pretty liberal with our permissions without worrying about destructive actions happening. Do note, however, that the container has full internet access enabled by default. So you are still potentially vulnerable to exfiltration attacks and prompt injections. But if that were to happen, your host machine will at

exfiltration attacks and prompt injections. But if that were to happen, your host machine will at least be unaffected. You can optionally disable internet access by starting Yolo box with a -no network flag. And this will completely isolate the container. For example, if we say curl Google.com, we'll see it fails. The no network flag completely isolates the container. But using this entirely depends on how secure you want the container to be. Join me in the next lesson where we'll turn a Ralf script into a flexible CLI

But using this entirely depends on how secure you want the container to be. Join me in the next lesson where we'll turn a Ralf script into a flexible CLI and add Yolo box support to it. I'll see you there.