Connect Codex to your website project

Start from the project, not the live server

Codex works best when the complete application is in a local Git repository. The repository should contain the source code, dependency lock files, build instructions and safe example environment values.

Do not begin by giving an agent unrestricted access to a production document root. A local checkout provides reviewable changes, repeatable builds and a reliable way to reverse an incorrect edit.

• Clone the project to your computer or open the existing local repository.
• Confirm the repository does not contain live passwords, private keys or customer exports.
• Run the project locally and record the commands that install, build, test and start it.
• Create a Git checkpoint before asking Codex to make changes.

Open the project in Codex

1. In the ChatGPT desktop app, add or select the folder that contains the project repository. In Codex CLI, open a terminal in the project directory and run codex.
2. Use the local environment when you need Codex to run the same development tools installed on your computer.
3. Begin with a read-only request such as: inspect this project and explain its build, test and deployment process.
4. Check the active workspace and permissions before allowing edits or network commands.
5. Add project instructions describing the framework, required checks, protected files and deployment method.

Use a reviewable change workflow

1. Ask for one defined change and its acceptance criteria.
2. Have Codex inspect the relevant code before editing it.
3. Run formatting, type checks, tests and a production build after the edit.
4. Review the complete diff and check for unexpected dependency, configuration or permission changes.
5. Commit the verified result on a dedicated branch or checkpoint.

Connect deployment separately

A deployment connection should be a controlled tool, not permanent unrestricted server access. Use a dedicated SSH key or a Git-based deployment workflow with the minimum permissions needed for one website.

1. Create a restricted deployment user or website-level SSH account.
2. Keep the private key outside the repository and restrict access to the key file.
3. Document the server hostname, SSH user, port, release directory and health-check URL without recording the private key itself.
4. Require a backup, clean production build and explicit verification before the active release changes.
5. Keep the previous release available until the new site passes its health and content checks.