Token Management
WarnAudited by ClawScan on May 10, 2026.
Overview
This skill is meant to manage API tokens, but it tells the agent to read, list, persist, and potentially commit broad credentials in a fixed public/shareable location.
Install only if you are comfortable with the agent reading and modifying a central token file. Before using it, move secrets to a private secrets manager or locked-down directory, never commit .env files, avoid printing full tokens, and require explicit approval before any saved credential is used.
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 could gain access to multiple important third-party accounts from one local file and may use tokens with write or repository permissions.
The skill instructs the agent to read a central local credential file and shows broad third-party account scopes, but it does not bound which credentials may be used or require per-token user confirmation.
**ALWAYS check `~/Documents/life/.env` FIRST before asking for tokens!** ... | GitHub | `GITHUB_TOKEN` | repo, gist | ... | Jira | `JIRA_TOKEN` | read-write |
Use least-privilege tokens, require explicit user approval before reading or using each token, and prefer an OS keychain or secrets manager over a blanket always-read .env file.
Secrets or unrelated private files could be placed in git history or exposed in the chat/log output when listing tokens.
The suggested commands stage every file in the directory and print every token value, rather than using scoped, masked, or secret-safe operations.
If .env is in a git repo: `cd ~/Documents/life && git add -A && git commit -m "Before updating TOKEN_NAME"` ... `cat ~/Documents/life/.env`
Do not commit .env secrets, avoid `git add -A` for credential workflows, and replace token listing with masked output or service-specific lookups.
Long-lived local records could reveal which services you use and how to access them, and future agent tasks may over-trust stale or modified connection data.
The skill creates persistent cross-task records about tokens, capabilities, renewal links, and local skill state outside the workspace, but does not define access controls, retention, or safe reuse boundaries.
Create or update `~/Documents/life/connections/SERVICE.md` ... `Your index:` Keep your own list in this section (local copy of skill). ... `Survives workspace wipes`
Keep persistent token metadata minimal, protect the directory with strict permissions, avoid storing token values in documentation, and require confirmation before reusing saved connection information.
A user may believe the workflow is secret-safe while actually placing credentials where they are easier to share, sync, or expose.
The security framing conflicts with storing API secrets in a location explicitly described as shareable/public and designed to persist beyond workspace cleanup.
description: "... ensures token security ..." ... **Why here:** - ✅ Life infrastructure (shareable, public) - ✅ Survives workspace wipes
Revise the documentation to avoid unsupported security claims and clearly warn users not to store unencrypted secrets in public, shared, or synced folders.
Users may need to install or authorize tools separately, and should verify their source before using them with tokens or calendars.
The skill depends on external tools for testing and calendar reminders, while the supplied registry data has no install spec or required binaries; no automatic installation is shown.
dependencies: - python3 - requests - gog (for calendar reminders)
Declare dependencies in metadata and provide safe, pinned installation guidance or tell users to install them through trusted package managers.