The evolution of this codebase

[hscabral]

I've been using (and following) NanoClaw for a few days now. I've managed to successfully integrate WhatsApp, GMail, Calendar and some other things. By definition, code is generated to support new skills and adaptations, which seems to be a challenging scenario as far as contributions go, i.e., Pull Requests.

What is the plan to evolve the base functionality? For example, I've added support for processing WhatsApp images, and I saw that there are 2 Pull Requests addressing the same problem, but none of them is expanding or adding a new skill - which seems to be one of the core aspects of NanoClaw. When the agent acts on your codebase/repository/fork, it will invariably make changes that will most likely become conflicts in future updates.

Are you going to post guidelines about contributions? Because right now, assuming Claude does a lot of actual code work, once an instance of NanoClaw is alive and running, it would be very difficult to effectively perform updates. Perhaps some module or custom isolation outside the main service loop.

[cryptonique974]

I am wondering the same: how do we keep benefiting from the main branch updates while we're modifying the code on our side, without having to resolve conflicts each time we pull?

[alx]

This hits exactly what I've been running into too — every optional feature (Tailscale, extra docker config, scheduled tasks) ends up scattered across container-runner.ts, index.ts, db.ts, and the container entrypoint. Each one makes the next git pull harder.

I've put together a minimal plugin hook API that moves optional features out of core files into a plugins/{name}/ directory. It's available on a fork branch: feat: plugin hook API + tailscale plugin example

How it works:

plugins/tailscale/
|- hooks/
|-- env-vars.env # KEY=${env:VAR} → injected as docker -e args
|-- entrypoint-steps.sh # sourced in container before agent starts
|-- startup-tasks.json # DB tasks seeded on startup (with requireEnv conditions)
|- skills/
|-- tailscale/SKILL.md # auto-synced into each group's .claude/skills/

Two scan locations:

• plugins/ — bundled, tracked in repo
• .nanoclaw/plugins/ — user-local, gitignored, never conflicts with upstream

The core files (container-runner.ts, index.ts, etc.) now have no feature-specific logic — just a loop that reads from plugin directories. The tailscale integration I had in my fork is the bundled example; it's a complete no-op if TAILSCALE_AUTH_KEY isn't set.

What this means for the fork-divergence problem: anything you add via a plugin lives entirely in plugins/ or .nanoclaw/plugins/ and never touches upstream files. git pull stays clean.

The PR also extracts the Dockerfile's inline entrypoint script to a real container/entrypoint.sh file, which is a readability improvement on its own.

Happy to hear feedback on the structure before it merges — particularly whether .nanoclaw/plugins/ is the right convention for the user-local dir.

[hscabral]

@alx this is nice and in line with this discussion! Semantically I don't know if "plugin" is the right approach (thinking extensions or components), but this is a great initiative. Looking forward to seeing this merged.

[bahree]

Am curious - how you are using tailscale here? Is that in the container?

[wmalgadey]

I created a PR which resembles the plugin idea into a copy of the existing channels functionality, but sadly I didn't have the time to test this currently

#1387

[parktho]

i'm also keen for a solution here