Can't speak for the benefits of https://nono.sh/ since I haven't used it, but a downside of using docker for this is that it gets complicated if you want the agent to be allowed to do docker stuff without giving it dangerous permissions. I have a Vagrant setup inspired by this blogpost https://blog.emilburzo.com/2026/01/running-claude-code-dange..., but a bug in VirtualBox is making one core run at 100% the entire time so I haven't used it much.
Good question - and the answer is no, they cannot escape.
nono uses Landlock (Linux) and Seatbelt (macOS) - these are kernel-level security mechanisms. When a sandbox is created:
All child processes inherit the restrictions - if the agent spawns Python, Bash, or compiles and runs a binary, that process is equally sandboxed There is no API to remove or expand the sandbox - once restrict_self() (Landlock) or sandbox_init() (Seatbelt) is called, the restrictions are permanent for that process tree.
I rushed out nono.sh (the opposite of yolo!) in response to this and its already negated a few gateway attacks.
It uses kernel-level security primitives (Landlock on Linux, Seatbelt on macOS) to create sandboxes where unauthorized operations are structurally impossible. API keys are also stored in apples secure enclave (or the kernel keyring in linux) , and injected at run time and zeroized from memory after use. There is also some blocking of destructive actions (rm -rf ~/)
its as simple to run as: nono run --profile openclaw -- openclaw gateway
You can also use it to sandbox things like npm install:
nono run --allow node_modules
--allow-file package.json package.lock npm install pkg
Its early in, there will be bugs! PR's welcome and all that!
lol thanks! seriously, I have been running the tool over and over while testing and I kept typing 'nano' and opening binaries in the text editor. Next minute I swearing my head off trying to close nano (and not vim!)
Hmm, I don't know about better, more convenient I guess. But if it floats your boat you could write out everything in the sb format and call sandbox_exec()!
What sets DeepFabric apart from other dataset generation tools is its ability to ensure high diversity yet domain-anchored relevance through unique topic graph generation algorithms. This guides sample creation to cover all necessary subtopics while avoiding redundancy, which is where other tools often fall short, resulting in model overfit.
Constrained decoding and response validation, along with real tool executions within isolated webassembly environments, ensure that generated samples strictly adhere to structured schema, variable constraints, and execution correctness, ensuring datasets have exact syntax and structure for use in model training pipelines. Tool definitions can be directly imported from MCP server schemas and then mocked, or rans as real life tool functions. Using real tools means the model has to adapt and correct when it makes the wrong choice or hallucinationates which makes for much better training data.
Once your dataset is generated, it can be automatically uploaded to Hugging Face and directly imported into popular training frameworks like TRL, Unsloth, and Axolotl.
Post-training, DeepFabric's built-in evaluation engine assesses model performance, whereby models prove their capabilities on unseen tasks derived from training splits—covering evaluation-only questions, answers, and tool traces.
sure, just starting to get some up on HF. A good example might be GSM8K as this shows the structured output where every result is strictly formatted - I am using this right now to train models and managaing to get a small qwen model up in the 60% range, which wildly is higher then llama2 and xAI Grok 1
Very good, and even better with the new DAG approach - we have been using great-expectations to bench and seeing very good diversity and low amounts of duplication - you check out one of the recent CoT examples here: https://huggingface.co/datasets/lukehinds/deepfabric-devops-...
This dataset disappeared. Did it move or get pulled for some reason? (glanced at it when you noted this and went back today to check it out and found a 404...)
Ah right, kiln - Deepfabric was originally named promptwright , and I can see kiln has copied over some of our code and used it for its synth-gen (which is a nice compliment!)
We are actually planning on moving to graphs now, which we are seeing better results with over trees, check it out if you also want to use them in kiln - but you might want to wait until we validate a little more and lift it out of experimental.
I think the key difference between the two since kiln adopted the same approach is the ability to generate reasoning / chain of thought and export to alpaca, chatml, etc - along with direct to unsloth.ai's formatting. I doubt we will have UI as its for running on backend systems and part of an ML pipeline along with being a library / SDK.
I personally wrote Kiln's SDG code myself -- no code was copied from here or anywhere else. Not sure where that claim is coming from, but it's not accurate.
I might have taken some of the prompts and modified them. I didn't recognize the new name, do recognize the old one.
Edit:
- just confirmed. No code copied. Prompts were originally from the Pluto library, then modified by the library above, then modified again by me for Kiln.
- And just to clarify, Kiln has had supported for chain of thought, reasoning, and all major export formats (ChatML/Unsloth/OpenAI/Hugging Face). Plus API integrations with Together, Fireworks, OpenAI, Google Vertex.
People should try both. I just want to clear on the origins of the code/prompts, and the feature set.
# The contents of this file are adapted from the promptwrite library (https://github.com/StacklokLabs/promptwright),
# which was adapted from the pluto library (https://github.com/redotvideo/pluto).
I read the code. I also remember writing the code and that comment.
As disclosed: some prompt strings were taken and modified, but none of the code was. The original strings are using a templating library that we don't support, so their code/strings wouldn't have worked in our codebase, nor would the wrapping code. Those interfaces/LOC are all unique. It's possible for some "content" to be taken (partial prompt strings), but zero code, and the statement "copied over some of our code and used it" to be incorrect.
Not trying to make a big deal of this, just clarifying these are separate libraries, with no shared code. Looks like the author saw the comment and assumed we used code (vs prompts); not a big deal, but not the case. Their work is super cool, and did inspire parts of my project.
Also worth noting, the library Pluto originated this prompt (as far as I know), and it's been tweaked/evolved many times over.
Hey There, this thread is getting derailed. Could you please create a separate post for your project and we let this one be for discussion of deepfabric, thanks!
Agreed, and sorry about that. Maybe edit the incorrect comment about "I can see kiln has copied over some of our code" for clarity. I get it was probably honest mistake, but hard not to reply when people are claiming I copied something I didn't. Great project, people go check out deepfabric!
