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?

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.

i'm also keen for a solution here