NanoClaw
NanoClaw stops template skills from following dangling symlinks
NanoClaw proposes using lstat and explicit symlink checks while materializing template skills so broken links do not abort group creation or point outside the template root. A registry-drift report and structured-attachment patch expose adjacent packaging and provider-boundary pressure.
nanocoai/nanoclaw PR #3157 is the inspected primary source: “Don't follow dangling symlinks when materializing template skills.” The two related records below were inspected as supporting context, not treated as independent confirmation.
The facts
- nanocoai/nanoclaw PR #3157 was created 2026-07-30T17:14:10Z and was open at inspection; its title is “Don't follow dangling symlinks when materializing template skills.” - nanocoai/nanoclaw issue #3155 was created 2026-07-30T16:36:56Z and was open at inspection; its title is “registry branches have drifted from main; provider payloads fail their own install gates.” - nanocoai/nanoclaw PR #3156 was created 2026-07-30T16:37:15Z and was open at inspection; its title is “fix(agent-runner): carry channel attachments to providers as structured parts.” - The repository reported 30404 stars, 860 open issues, default branch main, and last push 2026-07-30T18:33:05Z. - The latest tagged-release baseline checked was v2.1.17 published 2026-06-17T14:51:14Z.
What changed
nanocoai/nanoclaw PR #3157 reports: Summary materializeTemplateSkills filters directory entries with fs.statSync, which follows symlinks. The store it reads (.claude-shared/skills) is also where container-runner's syncSkillSymlinks writes shared-skill links, and those point at **container** paths (/app/skills/ ) that never resolve on the host. So for any group that has both template skills and shared-skill links, the first stat of a link throws ENOENT. The throw escapes through the calling provider's container contribution into spawnContainer, so **no container starts for that group at all** — every message for that agent stalls, not just the affected skill. The
nanocoai/nanoclaw issue #3155 reports: What happens Running /add-codex on main at 0b034342 fails at the skill's own build step. I applied the skill mechanically (payload copy, barrel imports, CLI manifest entry) on that revision with the payload from providers at f2b75837, then ran the skill's step-4 typecheck: The registration and behavior tests all pass in the same composition (42/42 bun, 18/18 vitest). The guards are green while the build gate is red, so the tests cannot catch this class of drift. The providers branch also fails tsc against itself: its codex payload (updated in
nanocoai/nanoclaw PR #3156 reports: Type of Change [ ] **Feature skill** - adds a channel or integration (source code changes + SKILL.md) [ ] **Utility skill** - adds a standalone tool (code files in.claude/skills/ /, no source changes) [ ] **Operational/container skill** - adds a workflow or agent skill (SKILL.md only, no source changes) [x] **Fix** - bug fix or security fix to source code [ ] **Simplification** - reduces or simplifies source code [ ] **Documentation** - docs, README, or CONTRIBUTING changes only Description Channel attachments only ever reach a provider as
Why it matters
A template copier is a supply-chain boundary. It should copy regular files under a declared root, reject traversal and special files, and report skipped links rather than following whatever the host filesystem happens to resolve. 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-07-31. The release baseline was v2.1.17 published 2026-06-17T14:51:14Z. 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/3157. Supporting records are https://github.com/nanocoai/nanoclaw/issues/3155 and https://github.com/nanocoai/nanoclaw/pull/3156. 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
Test dangling, absolute and parent-escaping links; keep registry branches pinned to inspected payloads, and verify attachments retain MIME and filename metadata without broadening filesystem reach. 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.