Keep API Keys Out of a Codex Skill Your Team Shares
A Codex skill that launches an eval run against a hosted model needs an API key. The skill itself should never contain one.
In a dark software factory, a shared skill is a station every agent and every clone can run. That is exactly why it must carry no access of its own: access stays with the person or service that owns it, and the station only names what it needs.
OpenAI's skills documentation describes a skill as a folder with a SKILL.md (with required name and description) and optional scripts/, references/ and assets/. Repository skills live in .agents/skills, so they are committed and cloned with the code. Anything inside travels with every copy: into forks, into a paper's code release, onto a teammate's laptop.
The documentation does not cover secrets, so the rule is yours to set. Write the skill against a named environment variable such as EVAL_API_KEY. Give it a readiness script that reports whether the variable is set and never prints the value. Use obviously fake values in every example and sample output.
The check. Test both paths, then search.
env -u EVAL_API_KEY .agents/skills/run-eval/scripts/ready.sh; echo "exit $?"Expected: a nonzero exit and a message naming EVAL_API_KEY. With the variable set, the script should exit 0 and print only that it is set.
Then search the folder and its history for anything shaped like a credential:
grep -rnE '(sk-|api[_-]?key[[:space:]]*[:=])' .agents/skills/run-eval
git log -p -- .agents/skills/run-eval | grep -cE 'sk-[A-Za-z0-9]{16,}'Read every match from the first; none should be a real value. The second should print 0. A key that was committed and later deleted is still in the history, so rotate it rather than rewriting the file.
Test the trigger too. A skill that loads on the wrong request can start an expensive run nobody asked for; Chapter 7 of the book shows why a skill's exact words need testing.
