Codex for Infrastructure Changes You Can Review
Codex can help edit infrastructure-as-code repositories, but faster editing is not the same as safer infrastructure. A useful change should let a reviewer connect the request, source diff, proposed resource changes, and deployment decision without reconstructing the author's intent. For engineers using Codex through CodeRelay Hub, that discipline belongs in the repository and workflow, regardless of which model handles the request.
1. Define one infrastructure outcome
Start with a narrowly scoped task: add an object-storage lifecycle rule, change one service's replica count, or restrict one security-group ingress rule. Name the target environment and list what must remain unchanged. Avoid requests such as “clean up this module,” which invite formatting churn, resource renames, and unrelated upgrades.
Example instruction: “Update only the staging upload bucket's lifecycle configuration to expire temporary objects after seven days. Do not change production, provider versions, resource addresses, or bucket access policies.”
2. Give Codex boundaries before edit permission
Ask Codex to inspect repository guidance, module structure, version constraints, and existing tests before proposing edits. Have it identify the relevant files and explain its intended change first. Keep credentials, state files, and sensitive variable files outside its accessible workspace wherever possible.
Permit only the commands needed for the task. Do not grant cloud administrator credentials just to inspect configuration. Infrastructure deployment should remain a separate, explicitly approved operation, not a convenient follow-up to editing.
3. Preserve resource identity and repository conventions
Tell Codex to reuse existing naming, variable, and module patterns. A resource label that looks cosmetic can be part of Terraform's resource address; changing it without an appropriate migration can produce destructive actions.
Require an explanation for every changed resource address, provider constraint, module version, or lockfile entry. If the request genuinely requires a migration, separate that work from behavioral changes where practical. Reviewers should not have to distinguish an accidental replacement from an intentional one by inference.
4. Ask for the smallest complete patch
Have Codex edit only the configuration, tests, and documentation necessary to express the requested behavior. Reject unrelated sorting, comment rewrites, and repository-wide formatting. Small does not mean incomplete: a new input may still need validation, a module example, and a test.
Inspect the diff before running cloud-connected commands. Look specifically for widened access, wildcard permissions, public endpoints, disabled encryption, and changes outside the named environment. Treat generated explanations as claims to verify against the actual patch.
5. Run checks in increasing order of privilege
Start with local checks such as terraform fmt -check, then initialize the required modules and providers in a controlled environment and run terraform validate. Use the repository's established test and policy commands rather than inventing a parallel workflow. Initialization can download dependencies, so it also deserves explicit execution boundaries.
Next, generate a plan through the approved environment workflow. Use credentials scoped to planning where supported, recognizing that planning can still read sensitive infrastructure data. Codex should report which checks ran, their outcomes, and any checks it could not execute.
6. Review the plan as a separate artifact
A clean source diff does not prove a safe deployment. Compare the plan with the stated outcome, checking deletions, replacements, permission changes, and unexpected updates. Account for drift and provider defaults rather than assuming every planned action came from the patch.
Treat saved plans and machine-readable plan output as sensitive artifacts; they can contain secrets. Keep them in access-controlled storage instead of posting raw output in a public review. Summarize relevant actions without copying credentials or sensitive values.
7. Make the handoff explicit
Ask Codex for a pull-request summary containing the intent, affected environment, changed behavior, executed checks, plan findings, and remaining uncertainties. Require it to distinguish observed results from predictions. “Validation passed” must mean the command actually completed successfully.
Keep human approval between planning and application. Where the deployment workflow supports it, apply the reviewed saved plan rather than generating an unreviewed replacement. After deployment, verify the intended behavior and document recovery limits: reverting configuration does not restore deleted data.
Open a free workspace to try this workflow.