Claude Code can run unsupervised more responsibly when it is launched inside a Docker Sandbox, because the agent is isolated from other projects, files, credentials, and packages on the host machine. The workflow still requires reviewing the resulting pull request, and the sandbox can be deleted if anything looks wrong.
Behind this: 5 advice · 3 ai usage · 6 lessons · 5 limitations · 6 risks · 5 tools.
Searchable transcript of I Let Claude Code Run Unsupervised on a Real Repo (Here's What Happened) — Leon van Zyl (18:00). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by Leon van Zyl. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:00 We've all seen the horror stories by now. AI agents deleting production databases, wiping people's machines, and even leaking credentials. This is why a lot of people prefer to run claw code or codecs or coding agents in approval mode. For example, court will stop to ask our permission before running any dangerous commands. The problem with this approach is that it's painfully slow.
00:21 The agent will run for a few seconds, ask for approval, you hit approve, and then a few seconds later, it asks your permission again. For complex longunning tasks, this is not practical. Let's take my project autoforge as an example. This is a very real project with a lot of users. It's got nearly 2,000 stars on GitHub, and it also has a lot of open issues as well as pull requests.
00:44 And if I wanted to get an AI agent to triage these issues, it would take a very long time if I had to babysit the process and approve each and every request. Now, for a lot of people, this is where they'll simply set the agent to YOLO mode and just let it run through all the issues, make changes, create pull requests, and go wild. But on a project like this, it's not recommended.
01:06 And I wouldn't recommend it for you either. And here's the reason. Have you ever heard of something called prompt [music] injections? This is where you can trick an agent to perform an action that the user didn't expect. This can be a subtle piece of text or a command in a web page or for open-source projects, those instructions can be hidden away in GitHub issues and even in pull requests.
01:28 Keep in mind that for open projects like this, any random user can go and create an issue and I have no idea who they are and what their intentions are for this project. And you can easily imagine that an agent can open up any of these issues, go through its contents, and this could get the agent to install a malicious package or even leak credentials like SSH keys on our machine.
01:50 If you're trying to move away from being a vibe coder to a responsible agentic engineer, you really need to learn sandboxes. Sandboxes might sound intimidating, but the funny thing is it's stupidly easy to use. If you've used CL code in the terminal before, it's really just this small change. Instead of running claude in dangerously skip permissions mode, the command simply changes to this spx run claude.
02:15 And this will look very familiar to you. This is claude code. It's running in bypass permissions mode. So yolo mode, but this time it's running in a sandbox environment or its own virtual machine. This means instead of C code having access to your machine and all of your different projects, all of your credentials, everything that you've installed on your machine, it's now running in its own little virtual machine, also called a microVM.
02:36 And your agent is running in its own little environment and it can only access the files that are scoped to that environment. And of course, it can only install packages in that environment as well. And if things really fall apart, you can easily delete this environment and you don't lose anything. the risk is completely isolated and more importantly your development workflow is exactly like what you're used to.
03:01 To bring this home, let me just show you a quick example. So at the moment I've got this session running over here. I'll just call this one claude sandbox so that we can easily identify it. Then I'll just create another Claude code session running in dangerously skip permissions mode. So we've got these two sessions over here. They look and feel identical, but there is a massive difference.
03:24 So, in the non-sandbox environment, let's ask you to run this command. Please list all the files and folders one level above this current project folder. I'm going to grab this exact same instruction and let's pass it to the sandbox as well. All right, so back in the normal cloud code session, look at this. This can see all of our different projects.
03:46 And this is actually a bigger deal than you might think. So typically when you start cla code in a new project folder, it will ask your permission to access that workspace. But what if you also gave it access to the root or just the folder above that workspace like the projects folder in this case. This means Claude can actually jump out of the current project folder and dive into any of the siblings folder sitting at the same level of our current project.
04:10 I've personally had issues with this before where I'll create a new folder for a project, ask Claude to make changes, and I'll see Claude actually leave that current project folder to go to one of the other projects, and it will then kind of read the design system or the architecture and take inspiration from those projects, which is not what I want.
04:30 Each project is unique. So, I've had it happen with flagship models, by the way. This happened with Fable, with Opus 4.8, eight and it's really frustrating where if we go to the sandbox environment, check this out. So, this agent is saying it's got access to a project's folder, but there's nothing else in it. This is the only project in that project's folder.
04:50 So, it's only got access to autoforge and nothing else. Now, we can run a lot of different commands using this as well to expose API keys or secrets or SSH credentials. It is really scary what these agents have access to. But in the sandbox environment, we've got this peace of mind that this agent can't actually access any other files or folders or sensitive information on this machine.
05:15 So in this video, I'll show you how to set up Docker sandboxes so that you can run Cloud Code in YOLO mode in a responsible way. I'll also show you a more complex development workflow where we'll actually set up cla code to run in that virtual machine and we'll connect it to GitHub as well and set up a workflow where we can get the agent to triage all these open issues, make changes and even create pull requests that we can review.
05:38 Now, I do want to mention that there is a difference between a container and a docker sandbox. With Docker sandboxes, each sandbox actually has its own virtual machine or a microVM and each of those instances have their own kernel, their own file system, and their own network. And this is supported by all operating systems. So for each operating system, there's already this sort of hypervisor that's available to spin up these little machines.
06:05 And I've had people ask me before, is this not the same as sort of a dev container? And no, with Docker sandboxes, the instance has its own kernel, so it's a very different isolation class. Either way, if that was way too technical, please don't stress it's really easy to use. Now, I do have to mention that this video is sponsored by Docker, but Docker has been around for a very long time.
06:29 And if you've watched any of my videos, you know that I use Docker and Docker Desktop all the time. Now, Docker Sandboxes is finally stable enough to use. So, I am excited to start using this in my own projects. Installation is really easy as well. All you have to do is copy one of these commands. Since I'm using Windows, I'll just copy this Windows command over here.
06:48 Then on Windows, I'm just going to open up PowerShell and run that command. This will download and install Docker Sandboxes. And then all we have to do is run the command spx and log in. And this will ask you just to confirm this code. So I'm going to do that. And that's it. We're already set. This was really easy. And we can now close PowerShell, right?
07:12 To use Docker sandbox, it's it's very similar to what you're used to already. Simply open up the terminal in your project folder. And instead of running claude, what we'll do is run spx run claude. Now, if you are using codeex, you can just replace this with codeex or even something like co-pilot. They do support a few coding agents, but in this video, we'll have a look at Claude.
07:39 The first time you run this, it is going to create a new virtual machine. It will take a few minutes to set up the virtual environment, but afterwards, you will be asked this question. What sort of global network policy do you want to set up? So, you've got three options. You've got open, which means that all network access is available. So, the agent can go to any website.
08:00 [snorts] or if you go to lockdown agent will not be able to go to any website and you would kind of have to give very specific permissions on which domains or websites it's allowed to go to. Then we've got balanced. In balance mode all of the popular sort of development domains are available like npm as an example. It even says here that all the common dev sites are allowed.
08:23 So it will be able to download and install certain libraries from safe sources but it will not be able to I don't know go to Amazon as an example. So let's actually select balanced mode and cool now we're in claude code. So if this is your first time running claude code in this virtual machine you will have to run the /lo command and then just go through the workflow of authenticating with your subscription or your API keys.
08:47 Then I'll just say hey just to see if everything is working. And now we're running code in its own virtual machine and it's completely safe to run it in YOLO mode. All right. So, how do we then allow access to very specific domains? Let me show you something. Please go to anthropic.com and retrieve the latest news. All right. And what you'll notice is that we're getting these forbidden messages over here.
09:14 And our agent is also saying that it couldn't go to that domain because of the sandboxes policy to unblock direct fetches in the future. We can run this command over here. So I'm actually going to copy this. And if we go to a new session, we can paste in that command. And this added these new rules. Let's ask the agent try again. And this time the agent was able to access the Anthropic website.
09:38 So this shows you how strict the balance mode really is. But if you want to give the agent very specific access, just run this command and going forward, the agent will have access to these domains. So just before we move off permissions, there is one more thing I do want to show you. If you realize that you actually just made a mistake and maybe this policy is way too strict for you, what you can do is run the command spx policy and reset.
10:01 We can just say yes. And now we're back to that wizard. So if you want, you can move away from balance. just make it open or just lock it down, whatever you want. So for this demo, I'll just stick with balanced. Right. So for this development workflow, what I'm going to do is connect our Claude code instance to my GitHub repository. This will also show you how to securely store secrets in the sandbox environment.
10:27 That way, the agent can't leak it at all. All right, the first thing you need to do is to authenticate your GitHub account in the GitHub CLI. This is on your main machine. And this is not in the sandbox environment. So I'm not going to go through all the details, but you should have the CLI installed. If you're unsure if you already have it installed, you can run the command GitHub O and log in.
10:51 So if you get some error here, it means you haven't set it up yet. So just go ahead and install the GitHub CLI tool and authenticate your account. Now I've already done that, so I'm just going to exit out of this. Now what that step does is it actually stores our GitHub connection or our API key or our secret somewhere on our machine. Now we never want the agent to accidentally leak that information.
11:13 But one option you have is you could start up the sandbox and you could then ask CL code to set up the CLI tool for you and even authenticate your account. But that means that secret is now stored on the sandbox environment. So Claude could potentially leak that information if there's some kind of prompt injection. So what we'll do instead is store that secret in a super secure way in the sandbox environment.
11:38 And it's actually really easy. All we have to do is run this command get up or token. Then we'll pipe it to spx secret. Then we'll set a new secret globally called GitHub. This is simply going to sort of take the GitHub token from our main machine and just pipe it to the secrets in the sandbox. Press enter. And now that secret has been saved. This, by the way, is the Docker sandbox's recommendation for securely copying these tokens over.
12:07 Then what I'll do is run spx run claude. Then we can confirm that that secret was set by running the command spx secret ls. And this is really cool. We can now see that the sandbox only has access to two global variables at this stage. So we've got github and we've got anthropic, of course, because we're using clawed code. All right, so here's the thing.
12:28 When you add new secrets or environment variables, those environment variables will not be available within the sandbox automatically. You have to recreate the sandbox in order for the environment variables to become available. So, how on earth do you actually delete or recreate an environment? Well, what you can do is enter spxls and this will list all of the available sandboxes.
12:51 And yes, you can have more than one running on your machine and within this project as well. Now I only have one, so this is really easy. I'm just going to copy the name of the sandbox. Then we can run spx rm for remove followed by the sandbox name. Then let's just remove the sandbox. And cool. Then we can recreate the sandbox by running the command spx run claude.
13:18 And then I'm just going to check that everything worked by asking claude please run github or status. And if you set the environment variable correctly, this should tell you that you are now logged in with GitHub. So then let's give the agent a fun little task. So what I like to do is three different things. I like to ask the agent to triage all of the open issues.
13:38 Then I like a second workflow where I ask the agent to address sort of all the quick wins to make the actual changes and it should then also create a pull request for all of those changes. Then I'll typically have like a third agent that runs through all the pull requests and reviews them as well. So we can send the prompt like this. Please connect to the AutoForge GitHub repo and triage the open issues.
14:01 Use a workflow with multiple agents going through each issue. Finally, create an HTML file and sort the issues by priority and a TLDDR for each. And let's send this. To be honest, I didn't even check what model I'm using. So let [laughter] me just do that first. Let's go to model, which for some reason is set 4.6, which I definitely don't want to use.
14:27 Let's go with fable. Yes, let's switch to fable. And for the effort, let's just go with high, please resume. And let's send this. All right, then. Claw just created a workflow. So, we can press down and press enter just to see what this is up to. And this is running quite a few different agents. So it is running them in batches as well. So I can actually click right to go to any of these batches.
14:52 Let's press enter to go into this one. And from here we can get an idea of what these agents are up to. All right. So it just completed this normalized step as well. So I'll just press the back arrow just to go back to this main view. And the main workflow is done. The main agent is now just going to consolidate all of these results and create this issues.html file for us.
15:13 And that was actually surprisingly quick. I think this entire triage process only took like maybe 5 minutes to go through 81 issues. And that's actually a really big deal. You know, workflows definitely have its stigma. I'm not going to lie. You can definitely burn through credits unnecessarily fast. But if you have challenges like this that involve, you know, reading a lot of different objects or issues in parallel, workflows can be incredibly useful for that.
15:42 So Claw just created this issues.html HTML file. I'm just going to start it with live server. This gives me a very clear view of all the different issues in this project and sort it by priority as well. So we've got a critical issue that needs to be addressed. We've got high priority items. So you know just visually from a user point of view this is extremely useful.
16:04 And the beautiful thing is if I want I can just continue working on this. So, you know, I could just maybe create a new session, pull in the issues. So, what I asked the agent to do was to resolve the top five priority issues and create a pull request, use a workflow. So, Claude just simply kicked off a workflow and it's now investigating like the top five issues and within a few moments, it's going to start the implementation.
16:32 It's going to verify changes and by the end of it create its pull requests. And check this out. So claw just took about 40 minutes to do all of this and this workflow was quite busy. So it investigated the issues. It implemented five changes and it ran a verify and review step and at the end of it it gave us this GitHub repository. So this one over here and we've got this brand new pull request and all I have to do is just kind of read through it and if I'm happy with the results I can go ahead and merge this pull
17:04 request back into the main branch. So everything checks out. Even all of these checks have passed as well. So I can just really go ahead and if I'm happy with all of this, just merge this change. So here's a final thought for you. In this workflow, the pull request was the actual output. The sandbox is actually disposable. So if I think this environment contains anything that I don't like, then really all I have to do is exit out of cloud code, run the command spxls, grab the sandbox name, and then I can run the
17:35 command spx remove and that sandbox name. And now it's gone. It's completely disposable. Again, I want to thank Docket for sponsoring this video. You can try sandboxes for free, and I'll leave a link in the description of this video. If you like this video, then hit the like button and subscribe to my channel for more Aentic coding tutorials. I'll see you in the next one.