Free learning / Coding workshop

OpenAI Codex: from the first explanation to a reviewed change

Define the coding agent, prepare repository context and use the shared offline project to learn a reproducible engineering loop.

Begin reading Download a working copy

No account needed. Use your own copy for writing and keep the original as a reference.

Codex is OpenAI's coding agent. It can help inspect a repository, edit code and run development tools. A terminal is the interface where commands run; the CLI is a program launched there; a model helps the agent choose actions. The application you build remains a separate program.

This is original LockedIn Labs instruction. The examples use a fictional maintenance desk. No provider affiliation, certification or comparative performance result is implied.

1. Draw the two sides

On the development side, place you, Codex, the editor, Git and the test runner. On the application side, place the ticket-triage function and its trusted policy. A coding assistant can help build a program that makes no AI calls at all.

Predict: which process produces a test failure? Which part decides whether a foreign-tenant ticket is allowed? Who accepts the change?

The test runner observes behavior. Application code enforces the ticket boundary. The receiving engineer accepts evidence for the proposed change. A confident assistant message does none of these by itself.

UNDERSTAND THE SYSTEM

A coding agent works inside an engineering loop

Codex is OpenAI's coding agent. Follow a request through repository context, permitted actions and evidence you can review. The application you build is a separate program.

FOLLOW ONE EXAMPLE

See what moves and why.

Authored illustration

01 / EXPLORE THE PARTSTap a part to explain it

Direction of information or workReturn / feedback

Read the connections in plain English

01
You define the change → Repository + instructions
Keep the request small enough to inspect.
02
Repository + instructions → Codex
Give relevant files, the behavior contract and project instructions.
03
Codex → Permitted local tools
A proposed command still runs under environment controls.
04
Permitted local tools → Observed result
The test runner produces evidence about this copy of the code.
05
Observed result → Codex
Use the observed failure to revise the implementation.
06
Observed result → Review and hand over
Check behavior, scope and evidence before accepting it.

Check your understanding: Is adding an OpenAI API call necessary to learn Codex?

No. Codex assists software development. The project it edits can be a deterministic offline application with no model calls. Model access for the coding assistant and runtime model access for your application are separate.

2. Prepare the workshop

The six-lesson Academy course includes the existing protected offline coding project, also used in our Claude Code course. A shared project provides a stable engineering exercise; it is not a vendor benchmark.

Open the Codex course with your provisioned training access. Extract the supplied project into a new folder. Read README.md and package.json before running scripts. Use Node.js 24. The project uses the built-in test runner and needs no package installation or model key.

Code example

node --version
npm test
npm run demo

The starter deliberately contains behavioral defects. Keep the failed assertions as your baseline. A missing runtime or syntax error is a setup failure, not evidence that the behavioral test ran.

If Codex is approved and installed, use its normal sign-in flow and inspect the installed version. Begin with a read-only session:

Code example

codex --version
codex --sandbox read-only --ask-for-approval on-request

Ask it to explain the entry point, trusted policy, expected result and first observed failure without editing. Inspect actual permissions; project instructions do not enforce a sandbox. You can complete the code exercise manually, but label that mode accurately.

3. Write a useful context packet

Include the task, relevant files, behavior contract, observed failure and the point where exploration should stop. Keep credentials and unrelated customer information out.

Example request:

Text example

Inspect the triage function and its tests. Explain why a ticket from South
can become a draft under North's policy. Cite the files you read.
Preserve the existing assertions. Propose one bounded repair and an allowed
comparison case. Stop before editing until the plan is reviewed.

Use a short AGENTS.md in the disposable project for durable conventions and verified commands. A ticket body asking the agent to ignore tenant checks is untrusted data, not new authority.

4. Repair and inspect

After reviewing the plan, grant only the editing access appropriate to this training repository under your policy. Inspect the diff, retain the original tests and run them after the edit. Keep a valid North ticket beside the foreign-tenant refusal case: a patch that blocks every input is not a working repair.

Change one input in a separate copy: use a different allowed category while retaining the foreign tenant. Record your prediction and actual result. Do not call a passing narrow case a complete project repair if other assertions still fail.

5. Hand over evidence

Record the exact candidate, commands, runtime, relevant results and remaining limits. Inspect staged and working changes separately; a test on one version does not verify a different commit. A receiving engineer should be able to reproduce one useful result and one refusal.

Keep three decisions distinct: using an assistant, accepting a code change and authorizing deployment. This offline workshop does not deploy a service or connect a live customer system.

6. Connect the code to the system

Continue with Data, infrastructure and recovery. Name the authoritative data, derived indexes, server dependencies, infrastructure change owner and recovery objectives. Coding assistance is useful when it produces work another engineer can operate.

Keep a small receiving packet:

The original behavior and why it mattered.
The reviewed diff and exact code version.
Commands and actual results, including failures still open.
Tool/version used, or an explicit manual-work note.
One independent changed-input result.
The next environment observation needed before production ownership expands.

Sources and further practice

Official guidance checked 23 October 2026. Product interfaces and managed settings can change; use the provider documentation for your installed version.