RonanCodes/env

env — credential management inside the active env file

/ro:context decides which ~/.claude/.env.<context> file is active. /ro:env manages the credentials inside it: reading the right one, adding new ones safely, keeping it organised, and tracking exposures. Resolve the active file with ro context env (cwd-aware); ~/.claude/.env is a symlink to it.

The ownership model (read this first)

Every section of the env file is tagged with one of three owners. Never guess — the tag tells you.

| Tag | What | Cloudflare account | |---|---|---| | [SIMPLICITY] | Simplicity Labs company infra. Bare names (CLOUDFLARE_API_TOKEN, _ACCOUNT_ID, _ZONE_ID) are the Simplicity defaults, kept bare for skill compatibility; _SIMPLICITY mirrors them. | fcc16bad… ("[email protected]'s Account") | | [DATAFORCE] | The product (Simplicity × Taskforce). Runs on the Simplicity account; own keys always suffixed _DATAFORCE, or product-scoped (Google Ads, Shopify, Nango, Atlassian DAFO, ChatGPT GPT). | fcc16bad… (same account) | | [PERSONAL] | Ronan's own side-projects, NOT Simplicity. Suffixes _RONAN, _LEKKERTAAL, _ADHD; also Pushover/Telegram/Neon-"factory"/VAPID. | c421a1b2… (ronanconnolly.dev / [email protected]) |

The file carries a LEGEND + DEPLOY CHEAT-SHEET at the top mirroring this. The dataforce repo's memory reference_dataforce_cf_credentials mirrors it too.

Which credential for which deploy

| App | Token | Account | |---|---|---| | Dataforce | CLOUDFLARE_API_TOKEN_DATAFORCE | CLOUDFLARE_ACCOUNT_ID_SIMPLICITY | | Simplicity site | CLOUDFLARE_API_TOKEN (=_SIMPLICITY) | CLOUDFLARE_ACCOUNT_ID | | lekkertaal / adhd | CLOUDFLARE_API_TOKEN_RONAN | _ADHD | CLOUDFLARE_ACCOUNT_ID_RONAN |

which <app> → just answer from the table above + grep -iE '<app>' "$(ro context env)".

Multiple accounts for one service — DEFAULT PERSONAL, never Simplicity for a personal app

Several services have more than one account in the env file: a Simplicity Labs / Dataforce one and a personal Ronan Connolly one. The trap is that the unsuffixed/default key is usually the Simplicity one (kept bare for skill compatibility), so an agent that grabs the obvious key ships a personal app wired to the wrong account. This actually happened: smartcart.ronanconnolly.dev (a personal 12-in-12 app) was shipped sending OTP emails from [email protected] because the agent used the bare RESEND_API_KEY (the Simplicity account) instead of RESEND_API_KEY_RONAN.

The rule, every time you reach for a service credential:

1. CHECK first whether more than one account exists for that service. One grep:

   grep -i resend "$(ro context env)"        # → shows RESEND_API_KEY *and* RESEND_API_KEY_RONAN
   grep -i cloudflare "$(ro context env)"    # → bare token *and* _RONAN token
   

2. If more than one exists, do NOT blindly use the unsuffixed/default key. Work out which account the app belongs to (read the deploy domain, the repo owner, the project's CLAUDE.md / CONTEXT.md).
3. Default for a personal app = the personal "Ronan Connolly" account (_RONAN). A personal app is anything on ronanconnolly.dev, a 12-in-12 side project, a hackathon build, or anything under the discopenguin Cloudflare account. Only use the Simplicity Labs / Dataforce / Taskforce account when the app is explicitly one of those ventures (the repo lives under Simplicity-Labs, the project is Dataforce/Taskforce, or the user names it as company work).
4. If genuinely ambiguous, ask the user which account. Never guess.

Known multi-account pairs

| Service | Simplicity / Dataforce key | Personal "Ronan Connolly" key | Notes | |---|---|---|---| | Resend | RESEND_API_KEY (sends from simplicitylabs.io) | RESEND_API_KEY_RONAN (sends from ronanconnolly.dev) | Bare key is the Simplicity account — the trap | | Cloudflare | CLOUDFLARE_API_TOKEN (= _SIMPLICITY, account fcc16bad…) | CLOUDFLARE_API_TOKEN_RONAN / CLOUDFLARE_ACCOUNT_TOKEN_RONAN (account c421a1b2688f51a3713d99c3e875ef1d, the discopenguin / [email protected] account where ronanconnolly.dev + nutmeg + smartcart live; per-project tokens like _NUTMEG, _RONANCONNOLLY live on the same account) | Bare token is the Simplicity account | | Anthropic | ANTHROPIC_API_KEY_DATAFORCE | (none yet) | No generic personal Anthropic key exists yet; add one as _RONAN if needed |

This list will grow. When you add a new key for a service that already has one, always suffix the new one (_RONAN for personal, _DATAFORCE / _SIMPLICITY for company) and add a row here so the next agent does not fall into the same trap. The owner tags in the ownership model above are the deeper source of truth: [PERSONAL] suffixes (_RONAN, _LEKKERTAAL, _ADHD) are never the right pick for a Simplicity/Dataforce app, and the bare/[SIMPLICITY] keys are never the right pick for a personal app.

Adding / updating a secret — NEVER paste it in the chat

Default path (agent-driven): launch an interactive Terminal window so the human types the secret there. The value never enters the conversation, never hits a tool result, never lands in argv/ps.

bash "${CLAUDE_PLUGIN_ROOT:-$HOME/Dev/ronan-skills}/skills/env/scripts/add-secret.sh" --launch ANTHROPIC_API_KEY_DATAFORCE DATAFORCE "Workspace key, dataforce chat"

That opens Terminal; the user pastes the value at a hidden read -rs prompt. The script then, on the real env file (symlink resolved):

• takes a timestamped .bak.<ts> backup first (non-destructive),
• updates the line in place if the key exists (value passed via env var, never argv), else appends a tagged # [OWNER] … block at the end,
• verifies the write and restores the backup if it failed.

If the user is at the keyboard, they can run it themselves: prefix with ! in Claude Code, or run bash …/add-secret.sh --interactive KEY OWNER "comment" in any terminal.

Rule: if a user does paste a secret into the chat anyway, (1) still get it into the env (or wherever it belongs), and (2) immediately log it for rotation (next section) and tell them to rotate it — a value in the transcript is compromised.

Tracking exposed secrets (rotation queue)

When a secret is exposed (pasted in chat, screenshotted, committed), log it:

bash "${CLAUDE_PLUGIN_ROOT:-$HOME/Dev/ronan-skills}/skills/env/scripts/rotate-queue.sh" add CLOUDFLARE_API_TOKEN_DATAFORCE env "re-pasted in chat 2026-05-23"
bash "${CLAUDE_PLUGIN_ROOT:-$HOME/Dev/ronan-skills}/skills/env/scripts/rotate-queue.sh" list      # see everything still to rotate
bash "${CLAUDE_PLUGIN_ROOT:-$HOME/Dev/ronan-skills}/skills/env/scripts/rotate-queue.sh" done CLOUDFLARE_API_TOKEN_DATAFORCE

Queue lives at ~/.claude/.secrets-rotate-queue.md (gitignored). list also greps the active env for CHAT-EXPOSED / ROTATE comment markers. At the start of any session that will touch deploys/secrets, run list and nudge the user on anything still OPEN.

Organising the env file

Keep it self-documenting:

• Every section header gets a # --- [OWNER] … --- tag.
• The top LEGEND + DEPLOY CHEAT-SHEET is the single source of truth for the taxonomy.
• Edit comments and structure freely; never hand-edit a secret value (use add-secret.sh so you don't see it and can't typo it). The file is a symlink — edit the resolved target (readlink -f ~/.claude/.env), not the link.
• New project? Pick the owner bucket, suffix the keys accordingly (_DATAFORCE, _RONAN, …), and add them via add-secret.sh with that OWNER tag.

Relationship to other skills

• /ro:context — switches the active profile/file. ro:env operates within whatever it resolves.
• /ro:cf-ship, /ro:fly-deploy, /ro:cloudflare-dns — consume these credentials; point them at the cheat-sheet when they pick a token.
• /ro:setup-wizard — first-run onboarding; ro:env is the ongoing per-secret manager.

Provenance

• 2026-05-23 — created after a session where secrets (Anthropic key, Dataforce CF token) were pasted directly into the chat and the agent kept getting confused about which Cloudflare token/account to use for Dataforce vs personal apps. The interactive-Terminal add flow keeps secrets out of the transcript; the ownership tags + legend remove the which-credential confusion.