Codex app security workflow for trusted releases

OpenAI Codex CLI can read, edit and run across your repo quickly, so secure its config, MCP servers and dependency changes before shipping. This workflow shows how to lock down ~/.codex/config.toml using bearer_token_env_var, require approval for risky edits and collect SARIF for release evidence. Pair it with LyraShield as release assurance for AI built apps. Baseline context is in our vibe coding security guide, then apply Codex specific controls below for team use.

Map Codex to your threat model

Codex CLI operates with your terminal permissions. Any prompt can start reading docs, listing files, editing code and adding packages. That breadth is powerful but also risky if you grant production network or secret access to the same shell where the agent runs.

Typical AI assisted risk patterns include prompt driven addition of vulnerable packages, leftover debug endpoints that bypass auth and secrets passed as env vars that get echoed to CI logs. Treat each as a trackable finding with owner and mitigation date rather than an invisible change.

Use consistent references when triaging. OWASP Top Ten at OWASP Top Ten covers misconfiguration and vulnerable components that show up in AI generated back ends. Credential issues map to CWE 798 for hard coded credentials and command injection to CWE 78 for OS command injection. OpenAI platform updates and system guidance appear at OpenAI blog. For release SARIF handling, see GitHub docs at GitHub SARIF support.

If you also ship with Lovable or Bolt, review our Lovable app security checklist to keep your verification language consistent across builders while adapting config paths for Codex. That shared language helps reviewers track findings across different AI tools.

Harden config.toml and MCP servers

Codex CLI reads .codex/ config.toml from your home directory. MCP servers are defined under mcp_servers tables. This file is the control plane for external tools, so harden it like production config.

Follow the current openai-codex integration guide and manually merge the server entry, preserving existing settings. Authenticate local stdio separately with npx -y lyrashield@0.2.14 login --oauth and use @lyrashield/mcp@0.2.12. Use pinned CLI commands for documented config or skill installs; marketplace plugins remain separately gated. Restart the client, confirm discovery, then call lyrashield_list_workspaces for authenticated read-only access. CLI doctor does not establish client authentication or scan completion.

Secure example without inline secrets:

[mcp_servers.lyrashield]
command = "npx"
args = ["-y", "@lyrashield/mcp@0.2.12"]
startup_timeout_sec = 20
tool_timeout_sec = 60

[mcp_servers.lyrashield_remote]
url = "https://app.lyrashieldai.com/api/mcp"
bearer_token_env_var = "LYRASHIELD_API_KEY"
startup_timeout_sec = 15

Key hardening for teams:

Use bearer_token_env_var for remote MCP, not inline bearer_token. That keeps secrets in the shell env and out of git, shell history and logs. Keep startup_timeout_sec and tool_timeout_sec conservative so hung tools do not block verification or CI.

For local stdio, use npx -y @lyrashield/mcp@0.2.12 with env vars from shell loaded from your secret manager. The MCP protocol and auth expectations are defined at MCP specification and MCP authorization.

Review Codex CLI config guidance at Codex CLI repo and security notes at OpenAI Codex announcement. Require pull request review for any change to config.toml in team dotfiles repos and log which MCP servers were active for a given feature branch in your pull request description. That small log line helps reproduce permission issues later.

Scope permissions and project docs

Codex respects AGENTS.md or similar project docs at repo root. Use that file as explicit permission policy that is versioned in git.

Include three policy blocks:

Edit scope: allow src, tests and docs. Protect env files, secrets, infra and auth configs unless security owner approves. Deny direct edits to production workflow files and migration files that run automatically.

Command policy: allow npm run test and build and lint, require confirm for package installs and database migrations, deny curl with secrets, deny git push to main from agent context and deny unscoped docker commands.

Network policy: state which external registries or APIs the agent may call during generation and forbid arbitrary network egress or uploads of code snippets to unknown endpoints.

Pair policy with shell controls. Run Codex in a project scoped shell session that does not have production credentials loaded. Use temporary staging credentials with short expiry and rotate after heavy agent work. Ask Codex to write a short plan markdown before large edits and review that plan before execution. That mirrors plan mode ideas from other agentic tools and reduces blast radius when prompts are vague.

If the agent proposes broad regex replacements across many files, split them into smaller reviewed commits with tests. Broad replacements are where credential patterns or auth bypasses are most likely to be missed during review.

Gate supply chain and secrets

AI agents solve tasks by adding dependencies, which introduces supply chain risk if you do not gate it.

Run OSV checks via OSV database and your package manager audit on every pull request. Block high severity findings outright. Check lockfile diffs each PR: if a new transitive dependency appears with low download count or recent maintainer change, flag for manual review. Keep a documented exception process with owner, risk note and expiry date so exceptions do not live forever.

For secrets, scan with gitleaks or trufflehog and fail on new findings. Verify that bearer_token_env_var references point to env that is not logged. Check CI logs for accidental secret echo and redact if needed. The GitHub SARIF shape for upload is at GitHub SARIF upload.

Require that .env.example contains only placeholders. Production secrets belong in your secret manager, not in agent context or in committed config. Check that editor chat history is not pasted into issues with tokens.

Verify release with evidence

Make verification routine, not heroic, by automating evidence capture.

Steps per release:

1. Run lint, typecheck, secret scan and dependency audit locally and in CI.
2. Convert each tool output to SARIF where supported.
3. Upload SARIF to GitHub code scanning so findings appear in the pull request checks.
4. Write a short docs slash security evidence file listing active MCP servers, commit, scan tools run and reviewers.
5. Store build and SARIF artifacts with release tag for later audit.

That file plus SARIF provides a repeatable proof point for internal review and for later external assessment. Keep evidence for at least a few releases so you can show trend and closure of exceptions. See additional scan guidance at GitHub code scanning and MDN fetch security.

Area	Config location	Secure default
MCP auth	.codex/ config.toml mcp_servers with bearer_token_env_var	No raw tokens in file, env from secret manager, short timeouts
Tool scope	AGENTS.md policy and shell session	Edits limited to src and tests, protected paths need approval
Dependencies	CI with OSV and package audit	High severity blocks merge, lockfile diff reviewed, exceptions tracked
Secrets	gitleaks plus SARIF upload	No secrets in repo or logs, env files placeholder only
Plans	Plan markdown in pull request	Plan reviewed before broad edits, auth changes flagged with tests
Evidence	GitHub SARIF and docs slash security evidence	SARIF on PR and main, MCP list logged, release tag linked

Why pair Codex with LyraShield

LyraShield AI at https://lyrashieldai.com is release assurance for AI built apps. The loop is target, review, evidence, fix, retest, report: detection stays separate from proof, recorded scans contribute to an assurance record and fix proposals are approval gated so PR execution is blocked until a server generated patch is bound to the exact approval.

MCP integration fits Codex config.toml design. Stdio via npx -y @lyrashield/mcp@0.2.12 runs locally with env var secrets, remote at https://app.lyrashieldai.com/api/mcp accepts bearer_token_env_var for team use. The GitHub Action is diff-aware and emits SARIF candidate findings for changed files; it does not mark them as confirmed results or create a fix. SARIF output targets GitHub code scanning so results appear in your pull request.

Build honesty: LyraShield is live in open beta with open registration. The scan pipeline, findings and evidence, approval-gated fix proposals, retests, reports, billing and Local/Desktop flows are implemented. The runner-local Action provides an advisory diff gate with SARIF; production availability remains bounded by retained evidence and release gates. Automatic server-generated Fix PR execution is not enabled and self-serve checkout is live.

Final checks before you ship

Before merge and release, confirm these controls.

• Confirm config.toml uses bearer_token_env_var for all remote MCP and no raw bearer tokens are in file or dotfiles repo.
• Confirm AGENTS.md lists protected paths, command allow list and network policy.
• Run and upload dependency and secret SARIF to code scanning.
• Require tests and reviewer for auth, payment or file upload changes.
• Update security evidence file per release with MCP list, commit and reviewers.

Apply the same evidence flow with our AI app security checklist tool and create an account at https://lyrashieldai.com to start building assurance records today. For cross builder consistency, also review Bolt app security checklist and Replit app security checklist.