[CGamesPlay]

The blog post in question is on the site for Sketch, which appears to use Docker containers. That said, I use Claude Code, which just uses unsandboxed commands with manual approval.

What's your concern? An accident or an attacker? For accidents, I use git and backups and develop in a devcontainer. For an attacker, bash just seems like an ineffective attack vector; I would be more worried about instructing the agent to write a reverse shell directly into the code.

[cess11]

Bourne-Again SHell is a shell. The "reverse" part is just about network minutiae. /bin/sh is more portable so that's what you'd typically put in your shellcode but /bin/bash or /usr/bin/dash would likely work just as well.

I.e. exposing any of these on a public network is the main target to get a foothold in a non-public network or a computer. As soon as you have that access you can start renting out CPU cycles or use it for distributed hash cracking or DoS-campaigns. It's simpler than injecting your own code and using that as a shell.

Asking a few of my small local models for Forth-like interpreters in x86 assembly they seem willing to comply and produce code so if they had access to a shell and package installation I imagine they could also inject such a payload into some process. It would be very hard to discover.

[zahlman]

> For an attacker, bash just seems like an ineffective attack vector

All it needs to do is curl and run the actual payload.

[Wilder7977]

Or even the standard "echo xxx | base64 -d" or a million other ways. How can someone say that bash is not interesting to an attacker is beyond me.

[CGamesPlay]

But bash isn't a key ingredient in any of these. The exact same payload could easily be insert in the project's source code, and has the benefit of being persistent. Using a bash shell to do it might be the most obvious way, sure, but shutting down bash access is such a poor defense that it isn't worth doing.