Lark Calendar & Tasks
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill mostly matches its Lark calendar/task purpose, but it also exposes broad Lark API access, messaging helpers, tenant-level credentials, and broad employee-directory reads that need review.
Before installing, confirm the Lark app has only the minimum calendar, task, and contact permissions needed, understand that Boyang is automatically invited to created events, and review or remove the generic API/messaging helpers if you only want calendar and task automation.
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.
With the configured Lark app permissions, the skill code could be used to call Lark APIs or send messages outside the calendar/task actions a user expects.
The code exports a generic authenticated Lark API caller and IM message-sending helper, which can bypass the narrower calendar/task workflows described by the skill if imported or reused.
export async function larkApi(method, endpoint, { params = null, data = null } = {}) { ... let url = `${BASE_URL}${endpoint}`; ... } ... export async function sendMessage(...) { return larkApi('POST', '/im/v1/messages', ...); }Remove or keep the raw API wrapper internal, remove unused messaging helpers, and restrict callable endpoints to the documented calendar, task, and necessary contact operations.
A tenant access token can act with the Lark app's granted permissions, so mis-scoped credentials could allow changes beyond one user's personal calendar or tasks.
The skill uses an app secret to obtain a tenant access token, while the registry metadata declares no required env vars or primary credential.
const APP_SECRET = process.env.FEISHU_APP_SECRET; ... fetch(`${BASE_URL}/auth/v3/tenant_access_token/internal`, { ... body: JSON.stringify({ app_id: APP_ID, app_secret: APP_SECRET }) })Declare the credential and required Lark scopes explicitly, use a least-privileged app, and avoid installing with broad production tenant permissions unless intended.
The skill may access and expose broader employee-directory information than users expect for creating events or assigning tasks.
Name resolution fetches the root department and stores employee contact fields such as email, mobile, department IDs, and open_id, which is broader than simple name-to-user_id lookup.
department_id: '0', // Root department = all employees ... email: user.email, mobile: user.mobile, department_ids: user.department_ids, open_id: user.open_id
Limit directory queries and fields to what is needed for name resolution, avoid collecting mobile/email/open_id unless necessary, and clearly declare the contact-directory permission.
Every event created through the skill will include Boyang, which may share event details or send notifications even if the user did not name that attendee.
The behavior is disclosed, but it non-optionally changes the attendee list for every created event.
1. **Boyang is always added** as attendee to every calendar event (automatic)
Only use the skill if this business rule is intended, or add an explicit opt-out/confirmation before adding the automatic attendee.