Token Alert

Monitors Clawdbot session token usage and sends alerts at 25%, 50%, 75%, 90%, 95%, and 100% thresholds with a dashboard and Telegram notifications.

What to check before installing/use: 1) Review where API keys and tokens are stored: - Inspect scripts/providers/*.py and scripts/config.py to see whether provider API keys (Anthropic/OpenAI/Gemini) or Telegram tokens are read, and how they are persisted (plain file, plaintext JSON under ~/.clawdbot, localStorage, etc.). If keys are stored in files, ensure file permissions are restrictive or prefer env vars or encrypted storage. 2) Inspect auto-export and export/summarize logic: - Find exportMemory()/summarize() implementations (JS/Python). Confirm what 'export' does and where it writes or sends data (local file vs remote endpoint). Do not enable auto-export until you can verify no sensitive chat content is transmitted to unknown endpoints. 3) Audit network endpoints and proxy behavior: - Open scripts/proxy-server.py and dashboard/service-worker code. Ensure the proxy only forwards to your local Clawdbot/Gateway and does not proxy to external hosts or include any hard-coded remote URLs that would exfiltrate data. 4) Check installation scripts for system changes: - Look through setup-notifications.sh, notify.sh, start-dashboard.sh, and any plist/LaunchAgent files. These may install utilities (terminal-notifier, ImageMagick) or register a persistent LaunchAgent/cron job — only run them after you understand what they do. 5) Run in a controlled environment first: - Test the dashboard and check.py manually in an isolated VM or container. Use mock data mode (dashboard mentions USE_MOCK_DATA) to exercise behavior without connecting to real sessions. 6) Don’t add to automated HEARTBEAT or enable persistent agents until vetted: - The SKILL.md suggests adding checks to HEARTBEAT and running periodic scripts; only automate this after confirming no sensitive data is leaked. 7) If you plan to use Telegram/web push or provider integrations: - Prefer giving API keys at runtime or via secure config; check whether the code sends keys anywhere. For web push, note the repo says a server-side Web Push (VAPID) is not implemented; client-only notifications likely require manual consent. If you want, I can: - Summarize specific lines to inspect (e.g., search for 'requests.post', 'urllib', 'socket', 'fetch(', 'exportMemory', 'summarize', 'open(', 'write', 'subprocess') across the repo. - Highlight any suspicious code snippets if you paste the contents of scripts/check.py, proxy-server.py, setup-notifications.sh, and providers/*.py.

Type: OpenClaw Skill Name: token-alert Version: 1.2.0 The skill is classified as suspicious due to its use of a LaunchAgent for persistence on macOS (`scripts/setup-notifications.sh`, `scripts/notify.sh`), which is a high-risk capability, even if for a stated purpose (notifications). Additionally, the `proxy-server.py` and dashboard HTML files (`scripts/dashboard-v3.html`) contain a hardcoded `GATEWAY_TOKEN` (`d91a7a91e0d6bda8b6e3182467fda1f0bebd34c830263a4f`) for local API communication, which, while intended for local interaction, is generally poor security practice. The skill also accesses API keys from environment variables for external LLM providers (`scripts/providers/*.py`), which is expected for its functionality but adds to the overall risk profile.