A database URL usually contains the username and password, so a hardcoded connection string is a hardcoded credential. If OpenAI's Codex wrote one into your source and it reached a commit, treat those credentials as compromised. Rotate the database password first, then move the URL to an environment variable.
Why it's a problem
A connection string like postgres://user:password@host/db gives an attacker direct database access with no application in the way. In a public repo it is scraped within minutes, and from there someone can read, change, or delete your data or run up costs on a managed database.
How to fix it, in order
- 1Rotate the database credentials. Change the database user's password or rotate the credential your provider issues. This invalidates the exposed string.
- 2Check for unauthorized access. Review database and provider logs for connections or queries you did not make.
- 3Purge it from git history. Remove the string with filter-repo or BFG and force-push; rotation in step one is what protects you.
- 4Move the URL to an environment variable. Read it from process.env and confirm the .env is gitignored.
Why Codex does this
Wiring up a database connection is a common task, and inlining the full connection string is the quickest way to get it working. Codex produces running code, and the string ships with it unless you move it out.
Stop it happening again
Keep the connection string in a gitignored .env, add a secrets rule to AGENTS.md so Codex reads it from the environment, and install a gitleaks pre-commit hook.
The quick fix
- Rotate the database password immediately.
- Check database logs for unauthorized connections.
- Purge the connection string from git history.
- Move the URL to a gitignored .env.