Home » Guides » Codex Guide: Make Your First Reviewed Code Change
Coding agent / practical guide

Codex Guide: Make Your First Reviewed Code Change

Start with Codex using official setup instructions, a project checkpoint, AGENTS.md context, a focused coding task, and checks before committing your changes.

Research checked October 30, 2026 · SideHustleLab

Codex review cover by SideHustleLab

This Codex guide takes you from choosing the official setup route to checking a useful first result. If you are still deciding whether the product fits, start with our Codex review.

Before you begin: use an account and project you are authorized to access, a small non-sensitive sample, and a clear stopping point. Installation instructions belong on the device or environment you choose; reading this guide does not install anything.

Official downloads and mobile access

Codex mobile access uses the ChatGPT app to reach cloud work or a connected computer. The code runs in that environment, not as a local phone development setup. Follow OpenAI’s mobile instructions for account and rollout availability.

TerminalOfficial Codex CLI setup

Follow the installer for your operating system.

Desktop / browser / editorOfficial setup and interface choices

Choose local, editor, or cloud work.

iPhone / AndroidOfficial Codex mobile access guide

Uses the ChatGPT mobile app with cloud or a connected computer; availability varies.

How to get started with Codex

1. Choose the official Codex interface

For local repository work, use the official CLI or editor-extension instructions. For cloud work, follow the cloud-environment setup. The download and mobile links below lead to OpenAI’s documentation so you can choose the current route for your device and account.

2. Open a project with a recovery point

Use a project you own or are authorized to edit. Check the current Git status and create a checkpoint before the task. Keep an untouched copy if the project does not use Git. Identify any files or services that must stay outside the task.

3. Start a session in the project

After installing the CLI, open the project directory and run codex, then complete the available sign-in flow. Begin by asking it to explain the project and the commands used to check it. This exposes missing setup before you ask for a change.

4. Add concise project context

Use an AGENTS.md file for project-specific guidance such as the purpose, test commands, important directories, and deployment boundaries. Keep it factual and maintainable. Do not put passwords, API keys, or private customer records in a committed instruction file.

5. Request one testable change

Give the agent the issue, expected behavior, constraints, and definition of done. For a UI bug, include the viewport and steps to reproduce. Ask for a focused change and require it to distinguish observed results from assumptions.

6. Review permissions and the proposed work

Check which files and commands the session can access. Choose controls appropriate to a development copy. If a command needs access beyond that scope, understand the reason before approving it. Review the actual diff instead of approving solely from the final summary.

7. Run checks and save the result

Have the relevant checks run, inspect their output, and manually exercise the changed behavior where practical. Commit the reviewed result to your branch. Treat deployment as a separate step with its own verification, not an automatic consequence of a passing local check.

Sources: Setup and interfaces.

A practical first task

Use a development copy with a reproducible narrow-screen problem. Save a before screenshot and check the same width afterward. A successful result preserves the existing menu behavior, fixes the overlap, and does not quietly change unrelated pages. The example is a suggested test task, not a benchmark score.

Example prompt to adapt

Inspect this project and explain how the navigation is rendered. Then fix only the mobile menu overlap described in the issue. Preserve existing routes and styling outside the affected layout. Run the relevant available checks, show the changed files, and report any checks you could not run. Do not deploy.

What a good result looks like

  • The deliverable matches the requested scope and uses the supplied inputs.
  • Claims or changes have evidence you can inspect, including source links or relevant checks.
  • The agent explains anything it could not verify instead of presenting assumptions as completed work.
  • No unrequested external action is treated as part of the task.

Common problems and what to check

Codex cannot see the right files

Confirm the selected project, working directory, and execution environment. A cloud task and a local task may not have the same filesystem.

It repeats setup questions every session

Put stable project facts in AGENTS.md and keep them current. Do not use a long conversation as the only record of how the project works.

The change looks right but was not tested

Ask what ran, what passed, and what was blocked. Arrange the missing verification before considering the work ready to ship.

Make the next run easier

Keep a short record of the input, output, correction time, and any usage charge. Repeat the same small task with one changed input before increasing the scope. If you cannot tell whether a result is correct, improve the acceptance checks before delegating a larger job.

Sources and editorial approach

This is a research-based editorial assessment of official product documentation, checked October 30, 2026. The suggested tasks and evaluation criteria are SideHustleLab examples, not claims of hands-on testing or guaranteed results. Product access, interfaces, and prices can change.

Scroll to Top