So, you are in the zone, right?
You clone this new open source repo to audit it, you spin up Claude Code to help
you, and boom, some hidden malicious prompt injection in a test file triggers a
command to upload your dot env secrets to some random IP.
And because you are clicking through prompts to get your work done,
you, uh, you just hit Enter.
You approve it.
It is what we call terminal prompt fatigue, and honestly, it is a massive security
disaster waiting to happen.
Oh, absolutely.
When you are in that flow state, you just want the tool to do its thing.
You are not reading every single network permission pop up.
It is like agreeing to terms of service, you just click yes.
And that is exactly why relying on developers to manually catch malicious curl
commands in the moment is a losing game.
By the way, today's episode is sponsored by Jellypod AI, the absolute best tool for
turning your daily newsletters and feeds into personalized audio podcasts,
so you can catch up on tech news like this while on the go.
But, Lachlan, back to the sandbox.
How do we actually stop this fatigue from compromising our keys?
Right, so in the Claude Code release, version 2.1.219, they introduced this awesome
fail closed feature.
It is a new configuration setting called sandbox dot network dot strict Allowlist.
And when you flip this boolean to true, the whole mental model shifts.
Instead of Claude Code stopping to ask you, hey, should I let this command talk to
this domain, it just silently blocks any domain that is not explicitly pre approved.
No prompts, no fatigue, just an immediate shut door.
Yes!
Fail closed is exactly what we need here.
So, how do we actually write this configuration?
What does the JSON look like?
It is super simple.
You can set it globally or drop it right into your project's local dot claudecode
slash settings dot json file.
You just open up the sandbox object, then nesting inside that,
you go to network, and then you set strict Allowlist to true.
And right next to that, you define your allowed Domains array.
So, if you only want it touching GitHub, you just add github dot com to that list,
and nothing else gets through.
Okay, but I can already hear the developers screaming because their build pipelines
are going to break.
If you turn this on, and Claude tries to run, say, npm install or pip install,
and those domains are not on your allowlist, what happens?
Oh, it is a total silent wall.
You will get these super cryptic connection timeout errors or DNS failures,
and you will be scratching your head wondering why your unit tests or package
managers are suddenly failing.
So, the trick is, before you run your agent tasks, you have to preemptively build a
checklist of the actual registry endpoints.
We are talking registry dot npmjs dot org, or pypi dot org,
or even your internal enterprise ones like JFrog Artifactory.
If they are not in that allowed Domains list, your builds will just grind to a halt.
Right, so you have to be really disciplined about defining those up front.
But let me push on the security side of this.
How secure is this sandbox proxy under the hood?
Like, how is it actually enforcing these domain limits?
Well, this is where it gets interesting.
The built in sandbox proxy inspects the unencrypted Server Name Indication header,
the SNI, in the TLS handshake.
It does this without decrypting or terminating the actual traffic.
But, because it is just looking at the SNI, a really clever attacker could use
domain fronting.
They put an allowed domain in the SNI header, but then send the actual request to a
completely different malicious server once the connection is established.
Oh, wow.
So the sandbox thinks it is talking to, say, github dot com,
but the traffic is actually routed to a malicious endpoint?
That is a pretty significant loophole for high security environments.
Exactly.
If you are in a hardened enterprise setup, you cannot just rely on the default SNI
inspection.
You need to close that final gap by routing all of your Claude Code traffic through
your own corporate forward proxy that does full TLS decryption and inspection,
using your own corporate Certificate Authority.
That way, you are inspecting the actual packets, not just the handshake wrapper.
That makes total sense.
Prevent the prompt fatigue with strict allowlists, but back it up with real proxy
controls if you are protecting the crown jewels.
Good stuff, Lachlan.
Thanks for walking us through version 2.1.219.
Catch you next time.
No worries, mate.
Talk soon.