2026 OpenClaw MeshMac: Per-Project Config & Log Paths on Shared Nodes

Audience and scope

This article targets operators who run more than one product line or customer tenant on the same physical Mac. You already SSH into MeshMac capacity and want OpenClaw workers that cannot read each other’s secrets or append to foreign audit trails. The commands assume macOS-style paths and root for provisioning, but checks use the unprivileged service account so you can paste output into tickets without redacting passwords.

For broader permission models on pooled hosts, read SSH, VNC, and shared-build isolation FAQ before you expand beyond automation users.

Pain points on shared nodes

1. Config drift via merges. When every team edits /etc/openclaw/config.yml, GitOps turns into last-writer-wins and midnight hotfixes hide in disk.
2. Log commingling breaks audits. A single /var/log/openclaw/app.log forces grep gymnastics and makes retention policies impossible to enforce per customer.
3. Over-scoped tokens. One API key that can enqueue every job or read every webhook secret means a compromised CI script becomes a full-mesh incident.

Decision matrix: log storage vs blast radius

Pick the lightest option that still matches your compliance story. Both patterns work with the same config split; only ownership and backup jobs change.

Step 1 — Project slug and POSIX principals

Choose a lowercase PROJECT_SLUG that matches your inventory tags. Create a dedicated group so ACL sprawl stays predictable.

export PROJECT_SLUG=acme-mobile
sudo dseditgroup -o create "ocproj-${PROJECT_SLUG}"
sudo dseditgroup -o edit -a "openclaw-${PROJECT_SLUG}" -t user "ocproj-${PROJECT_SLUG}"

Checkpoint: id openclaw-${PROJECT_SLUG} must list ocproj-${PROJECT_SLUG} as a secondary group. If it does not, later sudo -u checks will falsely fail.

Step 2 — Config directory layout

Keep rendered files under /etc/openclaw/projects/${PROJECT_SLUG}. Version-controlled templates stay in Git; the Mac only receives rendered output plus references to secret files, mirroring the workflow in least-privilege secrets on MeshMac nodes.

sudo install -d -o root -g "ocproj-${PROJECT_SLUG}" -m 0750 "/etc/openclaw/projects/${PROJECT_SLUG}"
sudo install -m 0640 -g "ocproj-${PROJECT_SLUG}" ./rendered/openclaw.yaml \
  "/etc/openclaw/projects/${PROJECT_SLUG}/openclaw.yaml"

Checkpoint: sudo -u "openclaw-${PROJECT_SLUG}" test -r "/etc/openclaw/projects/${PROJECT_SLUG}/openclaw.yaml" && echo OK. A random login user must receive “permission denied.”

Step 3 — Log volume or subpath

For subdirectory mode, use setgid so new files inherit the project group. Point rotation tools such as newsyslog or your orchestrator at this subtree only.

sudo install -d -o "openclaw-${PROJECT_SLUG}" -g "ocproj-${PROJECT_SLUG}" -m 2770 \
  "/var/log/openclaw/${PROJECT_SLUG}"
sudo chmod g+s "/var/log/openclaw/${PROJECT_SLUG}"

Checkpoint: create a throwaway file as the service user and confirm ls -l shows group ocproj-${PROJECT_SLUG}. If you mounted a separate volume, repeat the same ownership on its mount point before starting the daemon.

Step 4 — Minimal automation tokens

Issue credentials per integration surface: one queue, one webhook ingress, one registry pull scope. Store each file with mode 0440 and group ocproj-${PROJECT_SLUG}. Document the issuer, rotation date, and ticket id in your internal CMDB row, not inside the token file.

sudo install -m 0440 -g "ocproj-${PROJECT_SLUG}" ./ci_enqueue.token \
  "/etc/openclaw/projects/${PROJECT_SLUG}/secrets/ci_enqueue.token"

Checkpoint: attempt to read the file as another local user without group membership; it must fail. During rotation, overlap old and new tokens in separate files until traffic moves, then delete the retired file in the same change window.

Step 5 — Wire LaunchDaemon environment

Set explicit variables in the plist or wrapper script: OPENCLAW_CONFIG_ROOT=/etc/openclaw/projects/${PROJECT_SLUG} and OPENCLAW_LOG_DIR=/var/log/openclaw/${PROJECT_SLUG} (names illustrative—match your distribution’s documented keys). Reload the daemon and tail the project log while triggering a noop job.

sudo launchctl bootout system "/Library/LaunchDaemons/org.openclaw.${PROJECT_SLUG}.plist"
sudo launchctl bootstrap system "/Library/LaunchDaemons/org.openclaw.${PROJECT_SLUG}.plist"
sudo -u "openclaw-${PROJECT_SLUG}" tail -n 20 "/var/log/openclaw/${PROJECT_SLUG}/worker.log"

Checkpoint: log lines must include project=${PROJECT_SLUG} or an equivalent label you configure. Missing labels usually mean the process still reads a global defaults file—search for stale ~/.openclaw paths in the plist.

Troubleshooting matrix

FAQ

Should each project use a separate disk volume for logs? Volumes buy quotas and cleaner backup policies. Directories are fine when you monitor free space aggressively and rotate per subtree.

Can two humans share one OpenClaw config directory? Treat interactive developers differently from service accounts. Personal checkouts belong in user-scoped paths; production automation should never rely on merged human edits in /etc.

More OpenClaw topics: OpenClaw hub. Operations basics: help center; full blog list.