muninn-boot · v2.0.0 · 2026-09-19 · sha256 62d6097ce606dc6f
muninn-boot v2.0.0A
Immutable. This exact content is served forever at /api/v1/blob/62d6097ce606dc6f.
--- name: muninn-boot metadata: version: 2.0.0 source: https://github.com/oaustegard/muninn-utilities/tree/main/muninn-boot description: 'Puts oaustegard/muninn-utilities on the container Python path — runs scripts/boot.sh, which shallow-clones the repo (codeload tarball as fallback) and writes the .pth. The boot payload itself comes from the Muninn MCP connector: call its `boot` tool after this script. Trigger on the first message of any new Muninn conversation, or when the user says "boot up" / "boot" — unless the message contains "skip boot". Idempotent: a warm container exits in ~0s via a sentinel.' --- # Muninn Boot Two steps, in this order: ```bash bash "$(dirname "$(find / -name boot.sh -path '*muninn-boot*' 2>/dev/null | head -1)")/boot.sh" ``` then call the Muninn MCP `boot` tool. The script fetches code; the tool delivers identity, ops, recent memories and reminders. Memory reads and writes go through the connector's `recall` / `remember` / `forget` / `muninn_config` tools, so the container holds no Turso credential and this skill reads no `Turso.env`. Direction in memory ce3b8b75, the plan in 69f3301c. Prior to 2.0.0 this skill sideloaded claude-skills and ran the Python `boot()` itself. Marketplace sync now places claude-skills in every session (`/root/.claude/skills/synced/<id>/` in Cowork, `/mnt/skills/user` on Claude.ai), and the worker runs boot. "skinny boot" (`BOOT_MODE=perch`) has no effect until the worker's `boot` takes a mode. ## boot.sh steps 1. Warm-path check: sentinel `/home/claude/.muninn-booted` present and `/home/claude/muninn-utilities/muninn_utils` exists → exit 0. 2. Source `$MUNINN_PROJECT_DIR/GitHub.env` (default `/mnt/project`) if present. Transitional — it goes once GitHub write tools exist on the worker. The container presets `GH_TOKEN=proxy-injected`, a truthy placeholder; without the file, GitHub API calls from the container 401 and the script says so. Memory tools are unaffected. 3. `git clone --depth 1` `oaustegard/muninn-utilities` at `MUNINN_UTILS_REF` (default `main`; branch, tag or full SHA) → `/home/claude/muninn-utilities`. Measured 1.3s cold in Cowork. Fallback where the git proxy refuses github.com: the codeload tarball, which works on Claude.ai and is 403 in Cowork (there git works). If both fail the script exits 1. 4. Write `muninn-remembering.pth` at a site-packages directory resolved from `sys.path` at runtime (`/root/.local/lib/python3.11/site-packages` in Cowork, measured 2026-09-19) listing the repo, `remembering/`, `$HOME`, and every skill `scripts/` directory found under either skills root. 5. Write the sentinel, print a four-line footer: transport and commit, pth path, and the reminder to call the MCP `boot` tool. ## GitHub.env in Cowork Only `GitHub.env` matters now, and only for GitHub API work from the container. `project_read` it and write it to `/mnt/project/GitHub.env` with the Write tool (a bash heredoc carrying a secret trips the permission classifier), or skip it when the task touches no GitHub API. ## Pinning `MUNINN_UTILS_REF` defaults to `main`; the point of cloning is that changes land on the next cold boot with no version bump. Pass a SHA to test an unmerged state. `rm /home/claude/.muninn-booted` forces a re-pull in a warm container. This file and `boot.sh` are the one thing that cannot self-update: the running copy is whatever the session mounted (project upload or marketplace sync), so a change here needs a push to both `muninn-utilities/muninn-boot` and the `claude-skills/muninn-boot` mirror, with `metadata.version` bumped.