Refuse bash instead of silently running unconfined when the OS sandbox backend is unavailable

[Luteva-ssh]

Summary

Today, when the sandbox is meant to be on but the OS-level backend can't actually confine bash — the Landlock probe fails on an old kernel or inside a container whose seccomp profile blocks it, or on Windows the dedicated sandbox user was never set up via 3code setup — 3code silently falls back to running bash completely unconfined. On POSIX there is no notice of this at all; on Windows there's a startup warning, but nothing stops bash from running unconfined anyway.

For an agent that autonomously issues shell commands, a warning the human may or may not read before the first tool call isn't a meaningful safeguard. This PR changes the behavior to fail closed: bash calls are refused with a clear error when the backend isn't actually confining them, unless the operator explicitly opts in with a new --danger flag.

Changes

types.nim: new dangerConfirmed: bool global, set only by --danger, deliberately never persisted to [settings] or any other config file. It has to be passed again on every invocation.
sandbox.nim: new bashDangerRequired() — true when the sandbox wants to be on, the OS backend probe failed (procboxExe empty), and --danger wasn't given. A deliberate sandboxEnabled = false (:sandbox off / --no-sandbox) is a separate, explicit choice and is intentionally not gated by this — the person already opted out on purpose.
streamexec.nim: runStreamingBash checks bashDangerRequired() up front and returns a descriptive error instead of launching bash at all. read/write/patch are unaffected — those were already enforced in-process regardless of the OS backend, so there was no gap to close there.
threecode.nim: --danger flag parsing and --help text; the previously Windows-only startup notice about an unavailable backend now fires on any platform, with wording that matches the new refuse-by-default behavior instead of the old "runs unconfined" framing.
CHANGELOG.md: entry under Unreleased.

[capocasa]

Looking into it- thank you!

Not sure if a warning might do, I need a moment to think about that.

[capocasa]

Thank you!

I have modified your PR to print a warning instead of refusing to work- 3code puts functionality before safety-at-all-costs. But you can't run yolo without knowing any more.

Much appreciated!!! Please leave more issues and PR as needed, and feel free to reach out with feedback anytime.

[Luteva-ssh]

Hi,
thanks for getting back to me.
I’m somewhat surprised by the decision because for me, that is a deal-breaker.

First of all, the patch didn’t actually prevent people from working with 3code; it only blocked the completely unrestricted Bash access. The other read/write/patch tools remained available. In my view, giving an AI tool unrestricted access is absolutely unacceptable—especially since there have already been cases where an AI-Agent simply deleted an important database. 😡

I also wouldn’t be comfortable hiding such a risk behind a settings flag, because a few months later, people will likely have forgotten that the setting exists—especially when they just want to quickly try out a completely new model. 😱 Maybe I’m being a bit paranoid… 😨

Nevertheless, I do find the idea of a more token-efficient agent quite appealing. I’ll probably have to build my own solution, though. 🤷

[capocasa]

Oh!

I find your perspective interesting and my experience says if you can find a way to genuinely satisfy two opposing positions- not a compromise, creativity- the result is often pretty good. So if you're willing- let's hash it out!

So for one thing, let me share my reasoning. For one, I expect users to keep good backups, period. The risk of an agent deleting something is in my mind no greater than you fat fingering something in the terminal. During developing 3code, I had 0 incidents of accidental deletion and I ran it yolo the whole time. But I felt ok because I could lose a day's worth at most.

Then I believe the efficacy of sandboxes is overstated. Anthropic boxes guess what the effects will be from the prompt- so they trust a shitty model to police a good model. That's might catch a rm -rf but it wastes so many tokens.

Third- this whole 'AI is dangerous' shtick is a mixture between philosophical Angst- the kind of thing you can wonder about over 6 glasses of Absinth in a french cafe in the 1900s. It has NOTHING to do with LLMs. Those things can't escape, and all incidents involved directing the agent to be distructive- it just confused the target.

So for these reasons- I think your idea that the agent needs to hard limit use when there is no sandbox is completely overblown (using 3code with no bash is useless, it's a coding tool). I refuse to try and go over users heads for their own good- the machine ruling the users, forcing people to their own good fortune *that"s the dystopia.

Where I am perfectly open to discuss is sane defaults- a new user might benefit from a harder nudge to properly set the sandbox up.

So consider the settings flag! I'd also be very happy to further discuss, if you're interested.

If you prefer to write your own agent- go ahead! If you like 3code but really want it to police the user feel free to maintain an extra safe fork- that's what open source is for. But for now, if you like- I'd love to hash it out with you, if you're interested.