Obsidian Sync
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill behaves like a disclosed local sync server for Obsidian and Clawdbot files, but users should understand it can keep running and read or write configured workspace folders when given the sync token.
Install only if you want a local authenticated sync server. Keep it bound to localhost unless you intentionally expose it through Tailscale, protect the sync token, and narrow SYNC_ALLOWED_PATHS if you only want Obsidian notes synced rather than memory or other workspace content.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Anyone with the configured sync token can read or change files in the allowed sync folders while the server is reachable.
The server exposes authenticated HTTP endpoints that can read and write files under configured workspace paths. This is central to the sync purpose and is protected by bearer-token auth and path validation, but it is still file-mutation authority.
GET /sync/read?path=notes/x - Read file'; ... POST /sync/write?path=notes/x - Write file
Use a strong dedicated sync token if possible, keep the default localhost binding unless remote access is needed, and limit SYNC_ALLOWED_PATHS to only the folders you intend to sync.
Users may not notice from metadata alone that they need to provide and protect a sync/gateway token.
The skill requires a bearer token for access, but registry metadata lists no required environment variables or primary credential. The token use is disclosed and purpose-aligned, but the metadata under-declares the credential requirement.
SYNC_TOKEN="your-gateway-token" node scripts/sync-server.mjs ... `SYNC_TOKEN` | (required) | Auth token (use Gateway token)
Treat the sync token as a secret, avoid reusing broader account tokens if a narrower token is available, and update metadata to declare the required token environment variable.
Syncing the memory folder could expose or alter persistent agent context, not just ordinary Obsidian notes.
The default sync scope includes a folder named memory, and the write endpoint can modify files under allowed paths. If that folder is used as agent memory or persistent context, synced changes may affect future agent behavior.
allowedPaths: (process.env.SYNC_ALLOWED_PATHS || 'notes,memory').split(',').map(p => p.trim())Review the contents and role of the memory folder before syncing it; set SYNC_ALLOWED_PATHS to a narrower value such as notes if persistent memory should not be shared.
After setup, the sync server may continue running in the background and provide ongoing authenticated access to the configured folders.
The documentation includes a user-directed systemd setup that keeps the sync server running and can start it on boot. This persistence is disclosed and appropriate for a sync service, but users should understand it remains active.
systemctl --user enable --now openclaw-sync loginctl enable-linger $USER # Start on boot
Only enable the service if continuous sync is desired, and disable it with systemctl --user disable --now openclaw-sync when no longer needed.