Claw Alarm
AdvisoryAudited by Static analysis on May 5, 2026.
Overview
No suspicious patterns detected.
Findings (0)
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.
If used without care, alarms could be disabled, deleted, or changed at the wrong time.
The helper exposes mutable alarm operations and a broad API wrapper. This is aligned with the skill’s purpose, but users should notice that the agent can change or delete alarms when invoked.
Read, create, update, snooze, and delete alarms ... Every endpoint on the deployed worker is reachable through it
Require explicit confirmation before delete, disable, snooze, or broad update actions, and review the endpoint, method, and payload.
Anyone who obtains the token could read, create, modify, disable, or delete alarms on the paired phone.
The artifact acknowledges the bearer token grants alarm read/write authority, then recommends storage locations that can be shared, committed, or reused beyond the intended local pairing boundary.
anyone holding it can read and rewrite the alarm list on the paired device ... safe to commit the token to a project-local `CLAUDE.md`, an `.env`, or any other config file you'd normally pin to a repo
Treat the token as a real secret: keep it out of repositories and shared CLAUDE.md files, store it in a private untracked environment file or secret store, and reset pairing if exposed.
Future API changes could alter what the helper exposes without a skill package update.
The API surface is intentionally tied to a live remote spec rather than a pinned client. This is disclosed and purpose-aligned, but it means routes may change outside the reviewed package.
The CLI fetches the live OpenAPI spec from `/openapi.json` so the available routes, request bodies, and responses always reflect the deployed worker
Review the displayed route and payload before use, and prefer pinned API versions or explicit workflows for sensitive alarm changes.
The alarm-control token could remain available to future agent sessions longer than intended.
Putting a long-lived bearer token in CLAUDE.md makes the credential persistent agent context, where it may be reused or exposed across unrelated sessions or projects.
paste it into your `CLAUDE.md` so future sessions auto-load it without re-pairing
Do not store the token in persistent instruction/context files; use a private environment variable or local untracked secret file and rotate/reset pairing when needed.
A user may trust the guidance and accidentally expose a credential that controls their alarms.
This reassurance underplays the risk of committing a long-lived secret that the same document says can read and rewrite alarms on the paired device.
it is safe to commit the token ... You do not need a secrets manager
Revise the guidance to say the token is sensitive, should not be committed, and should be stored only in private local or managed-secret storage.