STOP Running Code on Your Computer  🔗 **Source:** [STOP Running Code on Your Computer](https://www.youtube.com/watch?v=-ulRSvQIObk) > [!note]+ Document Notes > > [!info] Analysis generated 2026-08-28 by Claude (Opus 5) via readwise-deep-read. > > **Source:** YouTube (Syntax) — https://www.youtube.com/watch?v=-ulRSvQIObk · ~2,805 words · released 2026-08-28. > > **Author:** CJ (Syntax podcast host; "My name is CJ. Welcome to syntax."). Reader's author field says "youtube.com." Syntax is Wes Bos & Scott Tolinski's web-dev show; this is a solo CJ explainer. > > Register key: [STATED] · [EVIDENCE] · [INFERENCE] · [RECOMMEND]. Full transcript read. > # 🏷️ Title: STOP Running Code On Your Computer (Isolation & Blast Radius) > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ## 📝 Summary > **The premise.** [STATED] Every dependency install, editor extension, build, or app run executes code you didn't write, with access far beyond your project directory. CJ demos a no-extra-privileges Python script that, in one command, scans the filesystem and grabs *"every cookie and session data from Firefox and Chrome, Slack, and Discord, as well as access to my npm token and SSH private keys — basically everything on my machine."* > **The threat.** [STATED] Supply-chain attacks via **transitive dependencies**: *"Your dependencies have dependencies… it's very possible that even though you're not directly dependent on some vulnerable package, their dependencies might be the victim."* The framing question: *"the main question isn't really if you'll install something compromised, it's when."* > **The concept — blast radius.** [STATED] If something goes rogue, what can it reach? On a bare dev machine: email, bank sessions, password vaults, SSH keys, .env files — everything. The fix: *"shrink that blast radius"* by isolating code execution from credentials and accounts. > **Four security principles** (apply at every isolation level): [STATED] (1) **least privilege** — give only what's needed (read-only DB creds if they work); (2) **egress/network filtering** — *"it can't phone home if it can't make requests"*; (3) **ephemeral environments** — use, destroy, nothing lingers; (4) **defense in depth** — stack layers, no single one suffices. > **Five rungs on the ladder of isolation.** [STATED] (1) **Containers** (Docker, dev containers) — OS-level virtualization, shared kernel, weakest (container breakouts happen); (2) **Virtual machines** (UTM/VirtualBox, Docker Sandbox microVMs, Lima/Colima) — hardware-level, harder to escape; (3) **Full separation** — a separate machine (VPS, GitHub Codespaces, self-hosted Coder); (4) **"Paranoid (potentially justified)"** — separate laptop, live OS (Tails), airgapped machine; (5) implicit — combine levels. [STATED] The floor recommendation: *"you should be doing at least level one, if not level two,"* combined with least privilege and egress filtering. > ## 📖 Main Content > ### The demonstration > [EVIDENCE] The opening demo is the argument: an ordinary Python script, no elevated privileges, exfiltrating browser cookies/sessions (Firefox, Chrome), app tokens (Slack, Discord), the npm token, and SSH private keys in a single command. [INFERENCE] The point is that "no extra privileges" is already catastrophic privilege — the user's own account can read everything the user can, which on a dev machine is the entire attack surface. This is why "I have no vulnerable direct dependencies" is the wrong mental model. > ### Transitive dependency risk > [STATED] *"Your dependencies dependencies have dependencies"* — a compromised package deep in the tree reaches end users who never chose it. [STATED] These incidents *"have increased in their occurrence over the past couple of years as more and more attackers leverage these developer ecosystems that we all thought we could trust."* [INFERENCE] This is the same supply-chain thesis running through Courtney's CLAUDE.md slop-squatting rule and this week's Pods/Wordfence reads — the ecosystem-trust assumption is the vulnerability, and "when not if" is the correct posture. > ### The four principles, sharpened > [STATED] **Least privilege**: read-only credentials where they work; *"don't run code on the same system that has stored credentials for other services."* **Egress filtering**: attackers exfiltrate by sending found secrets to a remote host — an environment with access only to *"specific servers, specific databases or specific package manager registries and not the entire internet"* defeats that. **Ephemeral**: destroy the environment and *"if there is anything compromised, it's completely gone."* **Defense in depth**: isolation alone doesn't protect the isolated thing — layer mounted-secrets limits and network limits on top. > ### The ladder, rung by rung > [STATED] **Containers** are the easy entry (Docker; dev container spec auto-connecting VS Code/Zed) but share the host kernel — *"if compromised code is able to break out of that container, it immediately has access to the host operating system."* Breakouts are rare but real. **VMs** get dedicated virtual hardware; breakout is *"a much harder technical feat"* — tools span GUI (UTM/VirtualBox) to scriptable (Docker Sandbox microVMs, which link one project dir; Lima; Colima wrapping Lima with Docker configs). **Full separation** puts dev on a different machine entirely (rented VPS/dedicated, GitHub Codespaces per-project, self-hosted Coder) — but a single big cloud dev box still doesn't isolate projects from each other. **Paranoid**: a spare laptop (CJ runs an old ThinkPad on CachyOS in his home lab), a live OS (Tails on USB, ephemeral by boot), or airgapped (*"unplug the literal Wi-Fi board"*) — with the acknowledged tinfoil limit (acoustic side-channels) waved off. > ### The closing prescription > [STATED] Do at least level 1–2; combine with the four principles; every isolation mechanism supports mounting only specific directories (not the whole host FS) and OS-level network blocks/firewalls for egress control; bring it together with defense in depth to *"reduce your overall blast radius if you do become compromised."* > ## 🗒️ Notes > - [INFERENCE] This is the defensive complement to Courtney's own daily workflow: Claude Code and agentic coding tools *are* "running code you didn't write," and the blast-radius framing is exactly why agent sandboxing/worktree isolation exists. The video's ladder maps onto the routing/isolation choices already in her tooling. > - [INFERENCE] Direct tie to the batch: the Pods fail-open bug and the npm/PyPI slop-squatting rule are the "when not if" made concrete; CJ's demo (npm token + SSH keys in one script) is what a successful supply-chain hit actually harvests. Pair this in the vault with the security reads, not the theology ones. > - [EVIDENCE] The concrete tool list is the reusable artifact: Docker Sandbox (microVMs, per-project dir), Lima/Colima (scriptable VMs reusing Docker configs), Coder (self-hosted Codespaces), Tails (ephemeral live OS). All named, all current. > - [INFERENCE] The strongest actionable is the least glamorous: egress filtering. Most supply-chain payloads are exfiltration; an environment that can reach only the package registry and your DB defeats the payload even after compromise. It's underused because it's annoying to configure, not because it's weak. > - [STATED] Honest scoping: CJ rates containers as real but weakest isolation and says so plainly ("container breakouts are rare, they do happen") rather than overselling Docker as a security boundary — a common overstatement he avoids. > ## 📚 References > [EVIDENCE] Named: **Docker** (containers, Docker Sandbox microVMs), **dev container spec**, **VS Code / Zed** (dev container connect), **UTM** (macO Every single time you install a dependency, run an extension in your code editor, run the build process for an app you're working on, or run the app itself, you are running code on your computer that you did not write. And that code has access to more than just your project directory. And just as an example, I have this simple Python script here. And I'm running this with no extra privileges. All it does is scan the file system. And with one single command, it has every cookie and session data from Firefox and Chrome, Slack, and Discord, as well as access to my mpm token and SSH private keys, basically everything on my machine. So, when an attacker's code gets onto your machine, it has access to pretty much everything. And attacker code can come from anywhere. But what we're probably most familiar with is supply chain attacks. Essentially, a package on some public repository gets compromised, and then when end users install that package, they get compromised as well. But it's not as simple as, oh, I don't have any vulnerable dependencies. Why should I care? Or why does this matter to me? Your dependencies have dependencies. And your dependencies dependencies have dependencies. These are [music] known as transitive dependencies. And it's very possible that even though you're not directly dependent on some vulnerable package, their dependencies might be the victim of some sort of supply chain attack. And that's how these things spread. And these are real incidents that have increased in their occurrence over the past couple of years as more and more attackers leverage these developer ecosystems that we all thought we could trust. And so the main question isn't really if you'll install something compromised, it's when? And so from there, the question becomes what can that code do? And that's what we're going to talk about in this video. I'm going to give you a basic primer on security concepts, how running code works, how what it has access to, and how you can limit that access. cuz that's really the basic concept that any sort of isolation mechanism or agent container allows us to do which is prevent the blast radius. If something gets compromised, you want to make sure that it doesn't have access to everything. So let's dive in. My name is CJ. Welcome to syntax. Now first let's talk about the blast radius which is if something goes wrong, what can it do or what does it have access to? And so if we consider your development machine today, let's say you run all of your projects locally, everything is happening just directly on your machine. If something gets compromised or goes rogue, it has access to everything on your computer. It has access to your email. It can check if you're logged into your bank. It can access any sort of password vaults, SSH keys, ENV files. Essentially, anything on your computer an attacker would potentially have access to if you are a victim of their attack. And so the fix is easy. Never run untrusted code on a machine that has anything that you care about. So we're essentially going to shrink that blast radius to zero by isolating code execution from your credentials and accounts. So the answer to this is isolation. When you're running a program, instead of giving it access to your entire computer, we can limit that access. And there are four security concepts you can apply to any one of those isolation levels that we'll talk about in the next section. And the [music] first security concept is the principle of least privilege. give it only access to what it needs. So maybe your program needs to talk to some hosted database. But will it work with readonly credentials? If so, use those. That way, if those credentials are compromised, they can't write anything to the database. Also, don't run code on the same system that has stored credentials for other services or other unrelated things to the project at hand. Now, number two, the next security concept is network filtering or egress filtering. that is, it can't phone home if it can't make requests. Now, one of the ways attackers take advantage of credential leaks like this are potentially if they can run code on your system, they will just send all of the secret data that they found off to some remote computer and then maybe later they can go look and try to use those credentials in certain places. But if your code is running in an environment that only has access to specific network resources like specific servers, specific databases or specific package manager registries and not the entire internet, that makes it much harder for an attacker to exfiltrate that data to some remote server or some remote system. Now number three, our next security concept is ephemeral environments. That is temporary environments. Essentially we can use the environment, [music] destroy it and then nothing lingers around. So if there is anything compromised, it's completely gone the moment we delete that isolated system. And number four, the last one is defense in depth. So no single layer of protection is enough. We essentially stack them. So we get more security guarantees with these layers of security. So isolation alone isn't going to prevent that one isolated thing from being compromised. We can do these other things like only mount the secrets that it has access to or only give it certain network access to limit that blast radius if that one isolated environment does become compromised. Now, how do we actually do all of this? I'm going to give you five ranks on the ladder of isolation you can choose from. And level one is containers. Now, if you're in the world of development, you've probably heard of Docker. And you may not be using it yet, but this is one of the easiest ways to get up and going with an isolated environment. You essentially define a configuration that says what operating system you're running, what dependencies does it have, what steps need to happen in order to set this container up to be ready for your project, and then the container runtime uses that configuration to automatically spin up a brand new environment that has everything ready to go. Now, containerization is operating system level virtualization. Essentially, every container that gets created gets its own set of processes that it can access, its own file system, and its own users. But each of these containers shares the host operating systems kernel. So this is a basic level of isolation because if compromised code is able to break out of that container, it immediately has access to the host operating system and in turn would have access to all of your files. Now while container breakouts are rare, they do happen. And so there are other levels of isolation that we'll talk about soon. Now related to containers is the dev container specification. Essentially, you define a container configuration specific to the development environment that you need for your project. And then there are various code editors like VS Code or Zed that can then look at that configuration, spin up one or more containers and automatically connect your editor instance to that running container. Then any file changes you make are automatically synced and any dependencies that got installed or editor extensions that ran or code that ran runs inside the container. Now, this is a great way to share your development configuration with your team and make it really easy for people to get up and going, but like we mentioned, it's running in a container, which isn't necessarily the best type of isolation. So, that brings us to level two in our ladder of isolation, virtual machines. Now, virtual machines are hardware level virtualization. Essentially, every virtual machine that gets created has its own hard drive, its own RAM, and its own CPU. And all of that is being shared from the host system. So each virtual machine gets its own dedicated resources. Now virtual machines are typically more resource inensive and sometimes slower to start up than containers, but they limit our exposure even more because breaking out of a virtual machine is a much harder technical feat. And so if vulnerable code does somehow get onto those virtual machines, it's very unlikely that it'll be able to break out to the host operating system. Now, there are a ton of different ways to get up and going with virtual machines. But one of the easiest ways is to use a program like UTM if you're on Mac OS or Virtual Box if you're on Windows or Linux. And this is just a guey application you can use to create virtual machines. Essentially, you can decide how much CPU they get, how much RAM they get. You can then boot them to a specific Linux or Windows installer. And now you have a virtual machine running on your computer. Applications like this are a good entry point, especially if you want to learn about Linux. Even if you're on Windows or Mac OS, you can boot up a Linux virtual machine and then play around with it and you don't even have to actually have a dedicated Linux machine. Now, using Guey applications like this is a little more cumbersome if you want to set it up for development because they're only scriptable or automatable in certain aspects. And if you want to create reproducible environments, it's a little bit trickier to do with these guey programs. One of the more automated and scriptable ways of spinning up VMs is actually from Docker and it's called Docker Sandbox. And it actually doesn't use containers. It uses what is known as microVMs. And with one command, Docker Sandbox will spin up a virtual machine that is linked to that one project directory that you're running the command in. [music] It has no access to other files on your system. And Docker Sandbox takes that same configuration file that you would use with Docker containers. So this is much easier to set up if you want more reproducible dev environments for your sandboxes. Now, another tool I came across is called Lima, and it essentially manages virtual machines for you, but from the command line. And there's also a tool called Kol Lima which only works on Mac OS and Linux but it's essentially a wrapper on top of Lima that makes it so that you can use your existing Docker configuration files to spin up virtual machines with Lima. Now let's move on to level three of separation. Full separation essentially you have an entirely separate machine for your development workflows. Now, you could go fully custom and rent a VPS or virtual private server or even rent a dedicated machine from some cloud hosting service and then set up that machine as your development machine and then anytime you need to do development work, you SSH into that machine. And that means if that machine ever gets compromised, it's not your computer. All of it is in the cloud. Now, just like all the levels of security that we talked about, if you have a big single dedicated development machine in the cloud, you're not necessarily isolating your projects from each other. And so if you have multiple projects with multiple credentials, you're not really adhering to the principle of of least privilege for all of the apps that are running on that development machine in the cloud. [music] So in theory, you could actually combine this with level two separation where you actually spin up virtual machines on that machine you have in the cloud. And then you basically have three levels of separation between you and the machine that that code is actually running on. Now, you could also go the more opinionated route and use something like GitHub code spaces. You can essentially spin up a code space for any one of your projects on GitHub and this gives you a machine running in the cloud that only has access to that one project. There also self-hosted alternatives like coder.com and you can essentially run this on your own VPS but you get a more streamlined interface where you can define what type of environment each project needs that you need to spin up. And that brings us to level four on the ladder of isolation which I'll label as paranoid which is potentially justified. And these scenarios all try to add as much separation between your computer with all of your secrets and everything you care about and the actual running code. And the first is just a separate laptop. Some of us potentially have old laptops we're not using anymore. And you might be surprised how performant some of these custom Linux distributions have gotten in terms of older hardware. And so I actually have one of these in my home lab. It's just an old ThinkPad running Cachio OS. And I use it as a development machine. So it's totally separate from my computer, but it's in my house. It's not even in the cloud. And so I'm able to run all of my development workflows that I need even on some of the older specs. And to get even more paranoid than that, you might actually use a live operating system. So this is used a lot by hackers or people that don't want to have any trace of anything they've done on a computer. They essentially use a live operating system like Tels OS where you could even boot into a live USB that has Ubuntu on it and you do all of your development work there and then the moment you shut down that laptop, it doesn't save anything because it was just running in that live USB environment. Now, this seems like a really cumbersome way to do some development in my opinion, but it's also totally possible to do. And because these are essentially ephemeral boots every time you boot up, it's a brand new, fresh operating system. You don't have any secrets or or anything that could be extracted by malicious code. And finally, this is hardcore tinfoil hat mode. You could use an airgapped machine. That is, go into a room, unplug the literal Wi-Fi board from your laptop, and do all of your development work there. And that way, if anything is compromised, it can't exfiltrate that data anywhere because there's no way for it to actually reach the internet. Now, there could be some secret spy device nearby that's actually listening to the sound that your hard drive is making or the sound that your keyboard makes when you're typing, and it could excfiltrate all of that data somewhere else, but we're not going to go there. So, these are the five levels of isolation. And if you really want to prevent yourself from being the victim of the next supply chain attack, you should be doing at least level one, if not level two. and combine these levels with the security concepts that we covered at the beginning, including the principle of lease privilege. That is give these isolated environments only access to the credentials that they need and nothing more. And every one of those levels of isolation I talked about has some sort of mechanism for only mounting or sharing a specific directory or specific files and not sharing your entire host file system. And with that, you should also do egress filtering. That is limit the network resources that any one of these isolated environments has access to. because if they do get compromised, they potentially won't be able to reach out to an attacker server or exfiltrate your data to an attacker's remote host. And every one of these isolation mechanisms supports firewalls or operating system level network blocks that can essentially lock down these isolated environments to only have access to the network resources that they need access to. And of course, to bring it all together, defense [music] in depth. combine all of these various security mechanisms with an isolation mechanism to reduce your overall blast radius if you do become compromised. So, that's all I got for you in this one. If you're using any of the tools I mentioned or have suggestions for other tools that people could use, let us know down in the comments. [music] And if you have any questions about setting any of this stuff up, let us know in the comments as well. All right, stay safe out there. I'll see you in the next one., STOP Running Code on Your Computer, CJ (Syntax), 01m14ax9z759t2tw5eqfvqg2nn.