# OpenAI Codex: from the first explanation to a reviewed change

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.

## 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](/app/academy?course=openai-codex&lesson=codex-101&view=focus) 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.

```shell
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:

```shell
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
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](/training/guides/systems). 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.

- [OpenAI: Codex CLI](https://learn.chatgpt.com/docs/codex/cli)
- [OpenAI: project guidance with AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md)
- [OpenAI: approvals and security](https://learn.chatgpt.com/docs/agent-approvals-security)
- [OpenAI: code review](https://learn.chatgpt.com/docs/code-review?surface=cli)
- [Free Git snapshot lab](/training/guides/git)
- [Free test-evidence lab](/training/guides/tests)