Calendar Hold Sync
PassAudited by ClawScan on May 1, 2026.
Overview
No malicious behavior is evident, but the skill uses Google Calendar OAuth to create, update, delete, and schedule private hold events, so users should review the config before use.
This appears to be a legitimate calendar-sync skill. Before installing, verify the gog CLI source, use calendar-only OAuth, start with dry-run and a test calendar, keep maxChangesPerRun low, review any custom command templates, and enable cron/watch only after confirming the mappings and privacy of the target calendars.
Findings (5)
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.
The agent may be able to read source calendars and write target calendar holds using your configured Google accounts.
The skill uses existing Google account OAuth access through gog. This is expected for calendar syncing and limited to the calendar service, but it grants access to read and write calendar data for configured accounts.
Require user OAuth already configured for each account used in `mappings`... Run `gog auth add you@gmail.com --services calendar`.
Use only calendar-scoped OAuth, review the mapped accounts/calendars, and test with dedicated calendars before normal use.
A non-dry-run reconcile can add, edit, or remove managed Busy hold events in target calendars.
The core workflow can mutate target calendar events, including deletions of managed stale holds. The dry-run and max-change controls make this purpose-aligned, but the user should notice the mutation authority.
Reconcile idempotently: - Create missing holds. - Update drifted holds. - Delete stale holds. ... Enforce `maxChangesPerRun`. ... Respect `dryRun`.
Run dry-run first, keep maxChangesPerRun conservative, and verify the SYNCV1-managed holds before allowing live changes.
Details from a source calendar may be copied into another calendar account even though the visible hold summary is just Busy.
The skill persists source event metadata, including the event title, into target event descriptions. Base64url is encoding, not encryption, so anyone or any app with access to target event details could decode it.
Store source linkage in hold `description` as: - `SYNCV1:<base64url(JSON)>` JSON fields: - `srcAccount` - `srcCalendar` - `eventId` - `start` - `end` - `title`
Keep target calendars private, avoid shared target calendars, and consider omitting source titles from metadata if they are not required.
Once enabled, scheduled sync may continue changing managed holds without a user manually running each reconcile.
The skill supports ongoing background-style operation through cron and polling watch mode. This is disclosed and fits scheduled calendar sync, but it can keep making calendar changes after setup.
`hold-sync install-cron --mapping <name>|--all` - `hold-sync watch --mapping <name>|--all [--dry-run] [--interval-seconds <n>]` ... Keep periodic scheduled reconcile as fallback even when watch mode is enabled.
Install cron/watch only after dry-run validation, document where it is installed, and know how to disable the scheduled job.
Installers relying only on registry metadata may underestimate the external CLI and account access needed.
The registry metadata does not declare the gog CLI or Google OAuth requirement, even though the skill documentation does. This is an under-declaration/provenance note rather than hidden behavior.
Required binaries (all must exist): none ... Primary credential: none ... Capability signals: No capability tags were derived.
Before installing, confirm gog is the intended CLI, verify its source, and understand that Google Calendar OAuth must be configured separately.
