Skip to content

fix(setup): mounts step writes correct allowlist format and syncs group container_config#418

Open
msaelices wants to merge 1 commit intoqwibitai:mainfrom
smithai:fix/setup-mounts
Open

fix(setup): mounts step writes correct allowlist format and syncs group container_config#418
msaelices wants to merge 1 commit intoqwibitai:mainfrom
smithai:fix/setup-mounts

Conversation

@msaelices
Copy link
Copy Markdown

Summary

Two bugs in the /setup mounts step that together caused additional mounts to be silently ignored even when the user configured them:

  • Wrong allowlist format — the step was writing mode: "rw" in allowedRoots entries, but mount-security.ts checks for allowReadWrite: boolean. Since allowReadWrite was undefined (falsy), every read-write mount request was silently downgraded to read-only. The step now normalises incoming entries: mode: "rw"allowReadWrite: true; canonical allowReadWrite boolean input is also accepted.

  • container_config never set — the step only wrote the allowlist (the security boundary that gates what can be mounted), but never updated container_config.additionalMounts in the registered groups table. container-runner.ts reads group.containerConfig?.additionalMounts to decide what to actually bind-mount, so without this the directories were never mounted at all. The step now upserts each allowed root into additionalMounts for every registered group after writing the allowlist.

Test plan

  • Run /setup and configure a directory (e.g. ~/projects) as read-write
  • Verify ~/.config/nanoclaw/mount-allowlist.json contains allowReadWrite: true (not mode: "rw")
  • Verify the registered group's container_config in SQLite contains additionalMounts with the correct entry
  • Send a message to the bot and confirm the directory is visible at /workspace/extra/<name> inside the container

…up DB

Two bugs fixed in the mounts setup step:

1. The allowlist was written with mode:"rw" which is not the AllowedRoot
   interface format. mount-security.ts checks allowReadWrite:boolean, so
   mode:"rw" was silently treated as read-only and the mount was rejected.
   The step now normalises incoming entries: mode:"rw" → allowReadWrite:true,
   mode:"ro"/anything else → allowReadWrite:false. Canonical allowReadWrite
   boolean input is also accepted directly.

2. The step only wrote the allowlist (the security boundary) but never set
   container_config.additionalMounts on registered groups in the database.
   container-runner.ts reads additionalMounts from the group DB row to
   decide what to actually bind-mount into the container, so without this
   the directories were never mounted even though the allowlist permitted
   them. The step now upserts each allowed root into additionalMounts for
   every registered group.
@rpolitex
Copy link
Copy Markdown

rpolitex commented Mar 2, 2026

This fixes a real pain point — I just hit this during fresh setup. The allowlist gets written correctly but directories are never actually mounted because container_config stays NULL. Core feature, clearly broken. Thanks for tracking this down and fixing both issues in one PR. Would love to see this merged soon.

Copy link
Copy Markdown

@darkostanimirovic darkostanimirovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - This comprehensively fixes the mount setup issue by both normalizing the allowlist format and syncing to container_config. Tested locally and works perfectly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PR: Fix Bug fix Status: Blocked Blocked by merge conflicts or dependencies

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants