Protecting Your .env File: API Key Security for OpenClaw Users

The most common credential mistake in OpenClaw setups is also the most avoidable: API keys hardcoded directly inside openclaw.json.

If your config file looks like this, you have a problem:

{
  "agents": {
    "model": "claude-opus-4-5",
    "apiKey": "sk-ant-api03-ACTUALKEY..."
  }
}

That key is now in plain text, potentially in a file with looser permissions than it should have, and at risk of being read by any process, subagent, or attacker who gains access to the config. Here's the right way to handle OpenClaw API key storage — and how to migrate if you're already doing it wrong.

---

Why .env Files Exist

The .env pattern exists specifically to separate secrets from configuration. Instead of putting your API key directly in openclaw.json, you reference an environment variable. The actual key value lives in a separate .env file with strict permissions.

Benefits:

• The config file can be shared, backed up, or committed to version control without exposing keys
• Permissions on the .env file can be locked to only the process that needs it
• Rotating a key means editing one file, not hunting through configs
• A subagent with read access to your workspace directory doesn't automatically get your keys

---

The Migration: Moving Keys Out of openclaw.json

Step 1: Create the .env file

# Create the .env file in your home directory (or wherever OpenClaw runs from)
touch ~/.openclaw/.env
chmod 600 ~/.openclaw/.env

The chmod 600 is mandatory. This sets permissions to owner-read and owner-write only. No other user or process can read this file.

Step 2: Add your keys to .env

nano ~/.openclaw/.env

Add each key on its own line:

ANTHROPIC_API_KEY=sk-ant-api03-yourkeyhere
OPENAI_API_KEY=sk-youropenapikey
TELEGRAM_BOT_TOKEN=your-telegram-bot-token

Save and exit (Ctrl+X → Y → Enter).

Step 3: Update openclaw.json to reference environment variables

Remove the hardcoded key and replace it with an environment variable reference. The exact syntax depends on your OpenClaw version, but the pattern looks like:

{
  "agents": {
    "model": "claude-opus-4-5",
    "apiKey": "${ANTHROPIC_API_KEY}"
  }
}

Check your specific OpenClaw documentation for the environment variable syntax, as it may use $ENV_VAR, ${ENV_VAR}, or a separate env configuration block.

Step 4: Verify permissions on both files

ls -la ~/.openclaw/openclaw.json
ls -la ~/.openclaw/.env

Both files should show -rw------- — that's 600. If either shows anything more permissive, fix it:

chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.openclaw/.env

Step 5: Restart OpenClaw and verify

openclaw gateway restart

Test that your integrations still work. If the agent can't connect to the LLM provider, the environment variable reference may need adjustment.

---

The Self-Audit Check

Once you've made the migration, run this prompt against your OpenClaw bot to verify no keys are still hardcoded:

Scan my openclaw.json config file and any other config files in my OpenClaw directory for hardcoded API keys, tokens, or secrets. Look for patterns like sk-ant-, sk-, Bearer tokens, and other credential patterns. Report what you find.

A clean result means the scan found no key patterns in your config files. If it flags something, that key needs to move to .env before it gets exposed.

---

Common Places Keys Get Left Behind

Beyond openclaw.json, check these locations:

SOUL.md People sometimes embed tokens or keys in their SOUL.md files while testing. Scan it:

grep -iE "(api_key|apikey|bearer|token|sk-ant|sk-)" ~/.openclaw/workspace/SOUL.md

Skill configuration files If you've configured custom skills that call external APIs, the skill config may contain hardcoded credentials:

grep -rE "(api_key|apikey|bearer|token|sk-ant|sk-)" ~/.openclaw/skills/

Memory files It's rare, but you may have previously pasted a key into chat (don't do this), and the agent stored it in memory:

grep -rE "(sk-ant|sk-|api_key)" ~/.openclaw/workspace/memory/

If you find a key in memory files, delete it manually and rotate the key immediately — you don't know what else may have seen it.

---

If a Key Is Already Exposed

If you realize a key has been hardcoded and potentially exposed:

For Anthropic Claude API keys:

1. Go to platform.claude.com
2. Navigate to API Keys → find the compromised key → Delete it
3. Create a new key
4. Update your .env file with the new key
5. Restart OpenClaw

For Telegram bot tokens:

1. Open Telegram and message @BotFather
2. Send /mybots → select your bot → API Token → Revoke current token
3. Save the new token to your .env file
4. Restart OpenClaw

For any other key:

1. Revoke/regenerate through the provider's console immediately
2. Assume the old key was used — check for unexpected API activity in the provider dashboard
3. Update .env with the new key and restart

The critical thing: revoke first, then investigate. Don't investigate a potentially live credential — kill it first.

---

.env Best Practices Summary

# Good: key in .env, config references variable
# ~/.openclaw/.env
ANTHROPIC_API_KEY=sk-ant-api03-realkey...

# ~/.openclaw/openclaw.json
{
  "apiKey": "${ANTHROPIC_API_KEY}"
}

# Permissions (mandatory)
chmod 600 ~/.openclaw/.env
chmod 600 ~/.openclaw/openclaw.json

# Never do this
# ~/.openclaw/openclaw.json
{
  "apiKey": "sk-ant-api03-realkey..."  # ← this is wrong
}

The .env pattern is a minor inconvenience during setup that prevents a major problem down the road. Once it's in place, you never think about it again.

[→ See also: OpenClaw Gateway Token Security: The Master Key You're Probably Mishandling] [→ See also: OpenClaw Self-Audit: The Prompt That Checks Your Own Security Setup]

---

Key Takeaways

• Hardcoding API keys in openclaw.json is the single most common credential mistake in OpenClaw setups. The fix takes five minutes.
• Create ~/.openclaw/.env, add your keys there, and reference them as environment variables from the config.
• Both openclaw.json and .env must have chmod 600 permissions — no exceptions.
• After migrating, run the self-audit prompt to confirm no keys remain hardcoded in config files, SOUL.md, skills, or memory files.
• If a key is already exposed: revoke first, then investigate. Don't delay revocation.
• Check everywhere: config files, SOUL.md, skill configs, and memory files all need to be clean.