OpenClaw Health

Generate a daily health brief from Oura, Whoop, and Withings. Unified re-auth script, local token persistence, Green/Yellow/Red morning summary.

Security Scan

The skill mostly does what its name/description claim (fetch and normalize Oura/Whoop/Withings data and persist rotated tokens), but there are documentation vs. implementation inconsistencies and a few operational choices that deserve attention before installation.

Purpose & Capability

Name/description match the code: connectors for Oura, WHOOP, Withings; normalization and Markdown rendering; token rotation and local persistence. Network calls, OAuth refresh flows, and local token storage are all expected for this purpose.

Instruction Scope

SKILL.md and README claim tokens are saved to both 1Password and ~/.openclaw/secrets/health_tokens.json 'automatically'. The implementation will persist tokens locally, but 1Password writeback only happens when OPENCLAW_1P_WRITEBACK=1 and the op CLI is available. The docs don't call out that writeback is opt‑in, which is an important behavioral difference. The cron example also sources ~/.openclaw/secrets/gateway.env — that file may contain unrelated automation/gateway credentials (the docs don't explain its contents), so the example could cause broader credential exposure if blindly copied.

Install Mechanism

There is no external installer or remote download; the repository is instruction + local Python code. No install spec (no arbitrary URL downloads) — lower install risk. All network interactions are standard HTTPS requests to provider APIs.

Credentials

The skill uses many environment variables (OP_SERVICE_ACCOUNT_TOKEN, OPENCLAW_1P_VAULT, OPENCLAW_1P_WRITEBACK, OPENCLAW_LOCAL_SECRETS_PATH, WHOOP_*, OURA_*, WITHINGS_*, OPENCLAW_FORCE_SAMPLE, etc.). Those are reasonable for OAuth access and optional 1Password integration, but the registry metadata lists 'Required env vars: none' which is misleading. OP_SERVICE_ACCOUNT_TOKEN in particular grants the skill access to 1Password items (via the op CLI) and should be treated as highly sensitive.

Persistence & Privilege

The skill persists rotated tokens to a local JSON file (~/.openclaw/secrets/health_tokens.json) with an atomic write and attempts to chmod 0600 — this is expected for token rotation. It can also write back to 1Password (via op) when enabled. The skill does not request system-wide privileges or modify other skills. However, the provided cron example sources an external gateway.env file (potentially containing other secrets) — copying that example without review could expose unrelated credentials to the automation.

What to consider before installing

What to check before installing: - Behavior is broadly consistent with the stated purpose (fetching from providers, normalizing, persisting tokens), but the docs slightly overstate behavior: 1Password writeback is NOT automatic unless you set OPENCLAW_1P_WRITEBACK=1 and have the op CLI and appropriate OP credentials available. - Review and decide where rotated tokens should live: by default the skill writes tokens to ~/.openclaw/secrets/health_tokens.json (attempts chmod 600). If you prefer not to keep local tokens, don't enable writeback or change OPENCLAW_LOCAL_SECRETS_PATH. - If you will enable 1Password writeback, treat OP_SERVICE_ACCOUNT_TOKEN as highly sensitive and ensure the service-account/vault have minimal scope. Confirm the 'op' CLI is installed and you understand the vault that will be targeted (OPENCLAW_1P_VAULT). - The registry metadata says no required env vars, but the skill will need credentials (either in 1Password or env vars) to fetch live data. Use OPENCLAW_FORCE_SAMPLE=1 to run smoke tests without credentials. - Inspect the cron example before copying: it sources ~/.openclaw/secrets/gateway.env — verify that file doesn't contain unrelated high-value credentials you don't want the periodic job to source. - If you can't inspect code yourself, run tests/smoke mode first, and consider running the skill in an isolated environment (container or VM) until you are comfortable with where tokens are stored and how writeback behaves.

OpenClaw Health Brief

Daily health metrics from Oura, WHOOP, and Withings → normalized JSON + Markdown brief.

Setup (3 steps)

Step 1: Configure secrets

Option A: 1Password (recommended)

export OP_SERVICE_ACCOUNT_TOKEN="your-token"
export OPENCLAW_1P_VAULT="Assistant"  # or your vault name

Create items in your vault with these titles and fields:

• OpenClaw Whoop → client_id, client_secret, token, refresh_token
• OpenClaw Oura → client_id, client_secret, token, refresh_token
• OpenClaw Withings → client_id, client_secret, access_token, refresh_token, user_id

See ./docs/1PASSWORD_CONVENTIONS.md for full field details.

Option B: Environment variables

# WHOOP
export WHOOP_ACCESS_TOKEN="..." WHOOP_REFRESH_TOKEN="..." WHOOP_CLIENT_ID="..." WHOOP_CLIENT_SECRET="..."
# Oura
export OURA_PERSONAL_ACCESS_TOKEN="..."  # or OAuth: OURA_REFRESH_TOKEN + OURA_CLIENT_ID + OURA_CLIENT_SECRET
# Withings
export WITHINGS_CLIENT_ID="..." WITHINGS_CLIENT_SECRET="..." WITHINGS_REFRESH_TOKEN="..." WITHINGS_USER_ID="..."

Step 2: Authorize providers

python3 ./bin/health-reauth all

This opens your browser for each provider. Click authorize, and tokens are saved to both 1Password and ~/.openclaw/secrets/health_tokens.json automatically.

You can also re-auth individually: python3 ./bin/health-reauth whoop

Step 3: Run your first brief

./bin/health-brief --date "$(date +%F)" --sources whoop,oura,withings --out "./out/daily_health_$(date +%F).json"

That's it. Token rotation is handled automatically — refreshed tokens persist to the local file so you don't need to re-auth again.

Add to OpenClaw cron

Wire it into your morning routine with an OpenClaw cron job:

openclaw cron add \
  --name "morning-health-brief" \
  --schedule "0 8 * * *" \
  --tz "America/New_York" \
  --session-target isolated \
  --message 'Run the health brief:
source ~/.openclaw/secrets/gateway.env
export OPENCLAW_1P_VAULT=YourVault
./bin/health-brief --date "$(date +%F)" --sources whoop,oura,withings --out "/tmp/daily_health_$(date +%F).json"
Read the JSON output. Report only non-null metrics with a Green/Yellow/Red rating.'

The cron job runs as an isolated agent session — it executes the brief, reads the output, and delivers a formatted summary to your preferred channel.

Smoke test (no creds needed)

./bin/smoke

Runs in sample mode, validates JSON schema. Good for checking the skill is installed correctly.

Troubleshooting

Check individual providers

./bin/whoop --date "$(date +%F)"
./bin/oura --date "$(date +%F)"
./bin/withings --date "$(date +%F)"

Common errors

• has_token: false → credentials not found. Check 1Password item names or env vars.
• refresh_failed → refresh token expired. Run python3 ./bin/health-reauth <provider>
• missing_credentials → client_id/client_secret not set.

Validate output JSON

./bin/validate-json --in ./out/daily_health_YYYY-MM-DD.json

References

• ./docs/1PASSWORD_CONVENTIONS.md — field naming for 1Password items
• ./docs/OURA.md, ./docs/WHOOP.md, ./docs/WITHINGS.md — provider API notes
• ./docs/MORNING_BRIEF.md — morning brief intent and format