openclaw/nix-openclaw
1
0
Fork 0
mirror of https://github.com/openclaw/nix-openclaw.git synced 2026-07-25 05:35:30 -04:00
Code Issues 31 Packages Projects Releases Wiki Activity

Nix-native birthing ritual for workspace bootstrap #12

New Issue
Open
opened 2026-02-15 17:04:28 -05:00 by yindo · 5 comments
yindo commented 2026-02-15 17:04:28 -05:00
Owner
Copy Link
Copy Source

Originally created by @joshp123 on GitHub (Jan 29, 2026).

Problem

We need a Nix-native birthing ritual for Moltbot workspaces. Upstream bootstrap is imperative; we want a ritual that only generates files, then lets users/agents adopt them declaratively.

Goal

Create a ritual that emits bootstrap templates outside the workspace, then uses Home Manager to symlink/adopt them into the workspace (no runtime writes).

Proposed shape

  • Add nix run .#bootstrap (or similar) that writes templates into /tmp/moltbot-bootstrap-<ts>/ by default, with an optional --out flag.
  • Extend programs.moltbot.documents to cover the full bootstrap set (AGENTS/SOUL/TOOLS/IDENTITY/USER/HEARTBEAT/BOOTSTRAP).
  • When documents are managed, set agents.defaults.skipBootstrap=true to avoid runtime writes.
  • Document the adopt flow (copy/symlink into a docs repo, then point HM at it).

Success

  • Users can run a ritual once, commit/adopt the files, and keep the workspace fully declarative.
  • No bootstrap writes during gateway runtime.
Originally created by @joshp123 on GitHub (Jan 29, 2026). ## Problem We need a Nix-native birthing ritual for Moltbot workspaces. Upstream bootstrap is imperative; we want a ritual that **only generates files**, then lets users/agents adopt them declaratively. ## Goal Create a ritual that emits bootstrap templates outside the workspace, then uses Home Manager to symlink/adopt them into the workspace (no runtime writes). ## Proposed shape - Add `nix run .#bootstrap` (or similar) that writes templates into `/tmp/moltbot-bootstrap-<ts>/` by default, with an optional `--out` flag. - Extend `programs.moltbot.documents` to cover the full bootstrap set (AGENTS/SOUL/TOOLS/IDENTITY/USER/HEARTBEAT/BOOTSTRAP). - When documents are managed, set `agents.defaults.skipBootstrap=true` to avoid runtime writes. - Document the adopt flow (copy/symlink into a docs repo, then point HM at it). ## Success - Users can run a ritual once, commit/adopt the files, and keep the workspace fully declarative. - No bootstrap writes during gateway runtime.
yindo added the enhancementmaintainer-roadmap labels 2026-02-15 17:04:28 -05:00
yindo commented 2026-02-15 17:04:28 -05:00
Author
Owner
Copy Link
Copy Source

@bcotton commented on GitHub (Jan 30, 2026):

The nix flake I use to manage my fleet is a multi-host, multi-arch, home-manager-included affair, where I deploy/switch at the host level, and all home-manager changes come along for the ride.

This project assumes that you are managing the home manager as its own unit, which would allow the bot to make changes and switch on its own. But that's at odds with my config style.

Is it the intent for this project for the bot to manage its own configs with Home Manager?

It might be good to have a separation of the systemd unit from the config, or teach openclaw to merge configs, or some such.

Related to the birthing ritual, and bot-managed configs in general. Would like your thoughts.

Thanks for the project!

@bcotton commented on GitHub (Jan 30, 2026): The nix flake I use to manage my fleet is a multi-host, multi-arch, home-manager-included affair, where I deploy/switch at the host level, and all home-manager changes come along for the ride. This project assumes that you are managing the home manager as its own unit, which would allow the bot to make changes and switch on its own. But that's at odds with my config style. Is it the intent for this project for the bot to manage its own configs with Home Manager? It might be good to have a separation of the systemd unit from the config, or teach openclaw to merge configs, or some such. Related to the birthing ritual, and bot-managed configs in general. Would like your thoughts. Thanks for the project!
yindo commented 2026-02-15 17:04:28 -05:00
Author
Owner
Copy Link
Copy Source

@joshp123 commented on GitHub (Jan 31, 2026):

@bcotton honestly we are a bit too early to really to describe what the project's intent is or not, at least in terms of the home manager issues that you describe.

I need to dive in a bit deeper (everything is on fire at the moment, we have one PR to the main repo every 2 minutes) and I'm trying to use this project to bootstrap our maintainer bots too, getting that under control. So, solid clean architecture will take some time :)

Come join me/us on discord if you'd like to help shape the architectural solution further! I'm by no means a nix expert, so any input is welcome.

@joshp123 commented on GitHub (Jan 31, 2026): @bcotton honestly we are a bit too early to really to describe what the project's intent is or not, at least in terms of the home manager issues that you describe. I need to dive in a bit deeper (everything is on fire at the moment, we have one PR to the main repo every _2 minutes_) and I'm trying to use this project to bootstrap our maintainer bots too, getting that under control. So, solid clean architecture will take some time :) Come join me/us on discord if you'd like to help shape the architectural solution further! I'm by no means a nix expert, so any input is welcome.
yindo commented 2026-02-15 17:04:29 -05:00
Author
Owner
Copy Link
Copy Source

@sookochoff commented on GitHub (Jan 31, 2026):

@bcotton are you running nixos?

@sookochoff commented on GitHub (Jan 31, 2026): @bcotton are you running nixos?
yindo commented 2026-02-15 17:04:29 -05:00
Author
Owner
Copy Link
Copy Source

@bcotton commented on GitHub (Feb 1, 2026):

@bcotton are you running nixos?

Yes

@bcotton commented on GitHub (Feb 1, 2026): > @bcotton are you running nixos? Yes
yindo commented 2026-02-15 17:04:29 -05:00
Author
Owner
Copy Link
Copy Source

@elsbrock commented on GitHub (Feb 4, 2026):

IMO it's intended to be writable by openclaw. I configured it so it can modify its configuration and just copied over the soul (not sure if it'd create that on its own).

Maybe we can support both modes?

@elsbrock commented on GitHub (Feb 4, 2026): IMO it's intended to be writable by openclaw. I configured it so it can modify its configuration and just copied over the soul (not sure if it'd create that on its own). Maybe we can support both modes?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
enhancement
maintainer-roadmap
pull-request
Mirrored from GitHub Pull Request
No Label enhancement maintainer-roadmap
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: openclaw/nix-openclaw#12
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?