NanoClaw
NanoClaw confronts the portability bill for container isolation
A NanoClaw patch reports two failures on rootless Docker: host UID mapping loses bind-mount access, then Claude Code rejects bypass permissions as container root. Older operator threads show the wider runtime split—restricted Kubernetes cannot expose Docker, while native mode would regain host tools by surrendering container isolation.
nanocoai/nanoclaw PR #3174 is the inspected primary source: “fix: support rootless Docker for agent containers.” The two related records below were inspected as supporting context, not treated as independent confirmation.
The facts
- nanocoai/nanoclaw PR #3174 was created 2026-08-01T21:06:25Z and was open at inspection; its title is “fix: support rootless Docker for agent containers.” - nanocoai/nanoclaw issue #1184 was created 2026-03-17T03:16:23Z and was open at inspection; its title is “Challenges deploying nanoclaw in restricted K8s environments (Sealos).” - nanocoai/nanoclaw issue #1732 was created 2026-04-10T18:29:43Z and was open at inspection; its title is “feat: native runner mode — bypass Docker for host-tool access (tmux, headed browsers, macOS APIs).” - The repository reported 30405 stars, 864 open issues, default branch main, and last push 2026-08-01T20:46:31Z. - The latest tagged-release baseline checked was v2.1.54 published 2026-08-01T20:46:31Z.
What changed
nanocoai/nanoclaw PR #3174 reports: Agent containers are unusable on a rootless Docker daemon. Two independent failures, both invisible when the host user is in the docker group — which is presumably why they haven't surfaced before. I hit them because I deliberately kept the agent account out of the docker group: on my host that group is root-equivalent, and docs/SECURITY.md makes a point of non-root execution and OS-level isolation. Rootless seemed like the setup the security model is written for. 1. --user mapping is inverted under rootless buildContainerArgs pushes --user ${hostUid}:${hostGid}. Under rootless the daemon runs in a user namespace where the invoking host user **is already container uid
nanocoai/nanoclaw issue #1184 reports: I really appreciate the minimalist approach and how it provides a lightweight, secure alternative to the more bloated agent frameworks. Using existing code agents to build such a streamlined "Claw" is brilliant. I've been eager to run this in my production environment, but I've encountered a challenge regarding deployment. Context I am attempting to deploy nanoclaw on **Sealos** (a cloud platform based on Kubernetes). In this multi-tenant environment, access to /var/run/docker.sock is restricted, and **Privileged Mode** is disabled for security reasons. The Problem Currently, nanoclaw seems to have a strong dependency on a local Docker daemon to spawn agent containers. This makes it difficult to
nanocoai/nanoclaw issue #1732 reports: Problem NanoClaw's container isolation is a security strength, but it becomes a hard blocker for a growing class of agentic use-cases that require direct host integration. There is no workaround short of mounting the host's entire filesystem. Blocked use-cases today 1. tmux-based coding agents** Skills like coding-agent and cloud-coding-agent spawn Claude Code or Codex sessions inside tmux. Inside a container this requires mounting the host tmux socket (/tmp/tmux- ), which introduces significant problems: The tmux socket path is not portable: macOS launchd sets $TMUX_TMPDIR to a non-default location; the socket may be at /private/tmp/tmux- or a user-specific temp dir that doesn't match the hardcoded pattern
Why it matters
Portable isolation is not one switch. Rootless Docker, restricted Kubernetes and native execution have different identity, socket and trust models; pretending they are interchangeable either breaks the agent or quietly broadens host access. This is an operator boundary: persisted state, execution ownership and visible controls must describe the same event. A workaround that broadens access, deletes state or hides the symptom would trade a visible defect for an unmeasured one.
Current
The primary record was open when captured on 2026-08-02. The release baseline was v2.1.54 published 2026-08-01T20:46:31Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/nanocoai/nanoclaw/pull/3174. Supporting records are https://github.com/nanocoai/nanoclaw/issues/1184 and https://github.com/nanocoai/nanoclaw/issues/1732. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Detect daemon mode from authoritative runtime state, fix the duplicated setup-container path, keep native execution opt-in, and document that host tools and strong multi-user isolation cannot both be inherited for free. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.