Pitfall Preferences jobs-apply

Openrouter Key In Zshrc Only

api-keysopenrouterzshrcjobs-apply

What Happened

During SaaS prep (2026-03-28), hardcoded keys were scrubbed from config/default.yaml. The stale old key stayed in ~/.zshrc. The pipeline failed with 401 errors and it looked exactly like a code regression. Significant time spent auditing call sites, headers, and request construction : all of which were fine. The key was stale. This pattern has repeated more than once.

Root Cause

Two sources of truth for the same credential. The app reads process.env.OPENROUTER_API_KEY set in ~/.zshrc, but the natural instinct after a code change is to search the codebase for the problem. The key lives outside the codebase, in a file that isn’t diffed or committed, so code review and git history provide no signal.

How to Avoid

  1. OpenRouter key lives ONLY in ~/.zshrc as export OPENROUTER_API_KEY="..."
  2. Never hardcode in YAML or JSON config files
  3. On 401: verify the key against the OpenRouter dashboard FIRST, before touching any code
  4. After rotating: source ~/.zshrc or re-export in the current session : the running shell does not pick up file changes automatically
  5. .openclaw configs also reference this key : update those too if rotating

Applies to any long-lived API key that gets rotated. The ~/.zshrc copy is the single source of truth; the app reads it via process.env.