Okay, I’ve been living in NanoClaw for a few weeks now, building little nano agents for home automation and data sorting. The container-first design is genuinely cool—each task spins up in its own isolated environment, which feels safe and clean.
But then I read the "Known Gaps" section in the docs. It starts to feel less like technical transparency and more like a liability waiver. Phrases like “under heavy concurrent load, isolation guarantees may degrade” or “shared volumes configured manually can introduce state leakage” are technically true, but they’re buried. I hit this myself:
* Running three document processing agents in parallel, all pulling from a shared volume. Saw one agent’s temporary files bleed into another’s workspace. The logs just showed “file not found” errors—no flag from the orchestration layer.
* The CPU pinning logic for containers seems to fall apart when you have more concurrent agents than cores. Throttling happens, but the isolation model doesn’t adjust—it just slows everything down uniformly, which feels like a gap between the promise and the practice.
I love the vision, and I’m still a huge fan of the local-first, open approach. But calling these “gaps” makes them sound like small, theoretical edge cases. In practice, they’re the exact scenarios you encounter when you start stacking agents for real workloads.
Has anyone else pushed the concurrency or shared volume setup and found the isolation boundary getting fuzzy? I’m curious how you’re working around it—custom orchestration hooks? Or just keeping workloads simple and spaced out?
--Ryan
--Ryan
That's not a documentation problem, it's an architectural one. Shared volumes are always a boundary break. If your isolation depends on not sharing state, then sharing state is the mistake.
The CPU pinning issue is real. They're using cgroups v1 for compatibility, which can't handle dynamic core assignment properly. It's a known trade-off they should just state directly.
You're expecting the tool to warn you about broken configurations. Good tools fail closed, they don't produce garbage logs.
Less is more.
You're right about shared volumes, but framing it as "always a boundary break" is precisely the cloud security cargo-cult thinking I'm talking about. In a data pipeline, you often *need* to share state. The architectural sin isn't the sharing, it's designing a system where that shared boundary is invisible and unmanaged.
The cgroups v1 choice is the perfect example. They traded a real, known isolation property for compatibility with older kernels, but the docs phrase it as "isolation guarantees may degrade." That's not a trade-off statement, it's a weasel clause. They should just say "we chose compatibility over strict isolation, so don't use this for multi-tenant workloads." Direct honesty beats vague disclaimers.
Good tools do fail closed, but they also expose their boundaries explicitly. The problem is NanoClaw hides the failure mode behind generic errors. It's the worst of both worlds: architecture that makes a risky trade-off, and documentation that obscures it with lawyerly caveats.