feat(module): let modules declare per-workspace bind mounts

[Banh-Canh]

Summary

A module.yml can now declare mounts: host paths bind-mounted into the containers of the workspaces that have the module installed, and only those. The global extraMounts applies to every workspace; this lets access to a host path be granted per workspace from the module editor, e.g. sharing a host login rather than copying it through resolve.

name: claude-auth-shared
version: 1
description: Share this host's Claude Code login with the workspace.
mounts:
  - source: ~/.claude/.credentials.json
    target: /home/debian/.claude/.credentials.json
    optional: true

Fields: source (absolute, or ~/-relative to the host home), target (absolute; not / or the workspace home), readOnly, optional (skip while source is missing instead of failing the start; the mount is added on the first start after it appears).

How it works

• provision collects the mounts of the manifest's installed modules (installedModuleMounts) and records a fingerprint in OCM_MODULE_MOUNTS_SHA256, so containerSpecDrift recreates the container when the set changes. They are added before the self-improvement mounts, so its conflict check covers them.
• AddModule records a mounting module in the manifest before starting the container, so its install already sees the mounts; the entry is rolled back if the install fails.
• RemoveModule recreates the container after the uninstall, so access ends right away.
• Mount points inside the workspace home are created on the host first (empty file or directory, owned by the user), so the runtime never creates them as root.
• Recreation interrupts a running task, so a module with mounts cannot set restartServer: false (rejected at load). The editor's idle guard then applies as for any restarting module.

Tests / docs

• internal/module: parsing, ~/ expansion, validation errors.
• internal/workspace: mounts only for installed modules, optional sources, fingerprint changes, mount point creation, required-source failure, AddModule ordering, drift cases.
• docs/writing-modules.md gains a Mounts section; AGENTS.md documents the lifecycle.

gofmt, go vet ./... and go test ./... pass. Used with podman on NixOS through a fork build to share the host Claude Code login with selected workspaces.

🤖 Generated with Claude Code

[Mickael-Roger]

Blocking issue: a failed add of a mounting module can leave the host path mounted in a running workspace even though the manifest rollback removes the module.

addMountingModule saves the module in the manifest, starts/recreates the container with its mount, then rolls only the manifest back if ensureStarted, value resolution, or the install script fails. It does not recreate or remove that already-running container. The code comments that the stray mount disappears on the next start, but until then the workspace retains access to the host path without any installed module granting it.

Please reconcile the container immediately after rollback so its mount set matches the restored manifest, and add a regression test that fails installation after the container is created and verifies the failed module mount is absent from the resulting container.

[Banh-Canh]

Thanks, fixed: after the manifest rollback, the container is now reconciled with the restored manifest right away, so it is recreated without the failed module's mounts (and stopped if that fails). Added a regression test that fails the install after the container is created and checks the mount is gone from the resulting container. Also rebased on main.