OpenAI Codex for Beginners: Build and Test Your First App

Free beginner course · one complete build

Build and test your first Codex app

Start with a safe practice folder, give Codex one exact brief, inspect the result, and prove that every control works. You will finish with a one-file Launch Checklist app you can read and reset yourself.

Step 1

Choose the Codex surface that fits your work

You can use Codex in several places. This lesson uses the ChatGPT desktop app with Codex selected because a beginner can choose a local folder, see proposed work, and review the result in one flow. If you already work in a terminal, editor, or configured cloud environment, the same brief and test habits still apply.

Interfaces and account availability can change. Check the official ChatGPT quickstart for current setup instructions.

Four terms you will see in this course

How to choose without overthinking it

If you can select a local folder in the ChatGPT desktop app, use that path here. Choose the CLI only if commands and working directories already feel familiar. Choose an IDE extension when you already use that editor and can tell which project it has opened. Codex cloud is useful when the source project and its environment are ready for remote work, but that adds account and repository context that this first lesson does not need.

The surface changes where you click and where work runs. It does not change your responsibility: define a narrow task, protect sensitive material, inspect the proposed scope, test the result, and decide whether to keep it.

Step 2

Give Codex a safe place to work

Create a new folder named codex-launch-checklist. Put nothing else in it. This boundary makes the task easy to inspect and easy to delete.

Create the practice boundary

1. Make the new codex-launch-checklist folder somewhere easy to find, such as your Documents folder.
2. Open that exact folder in Codex. Check the displayed path before continuing.
3. Confirm it is empty. A hidden operating-system file is harmless, but your own documents, credentials, and projects do not belong there.
4. Tell Codex that all work must stay inside the chosen folder and that it must ask before adding packages or using the network.

Folder permission is practical authority, not a formality. If you select a broad folder containing many projects, you make the review harder and increase the cost of a mistake. Start with the smallest useful boundary. Expand it only when the task genuinely needs another file and you understand why.

What a safe pause looks like

Stop before approval if the plan names a parent folder, a secret file, an unfamiliar command, a package installation, a remote service, or more files than the brief requires. Ask: “Why is this needed for the stated done criteria? Can you complete the task without it?” A good answer connects the action to a requirement. If it cannot, remove the action from scope.

This lesson has no production value to protect, so recovery is intentionally simple. On real work, recovery must be designed before editing: current backup, tested restore path, version history, and a named person allowed to approve the change.

The working method

Use the same five-step loop on every small project

1. Define. Say what you want, who it is for, and what finished means.
2. Plan. Ask Codex to inspect the folder and explain its intended changes before editing.
3. Build. Approve a small, bounded implementation.
4. Test. Run automated checks, then use the result like a real visitor.
5. Review. Read what changed, what could still fail, and how to undo it.

Each step produces evidence for the next one. The definition gives the plan a target. The plan gives the build a boundary. The build creates something testable. The tests give the review facts. The review decides whether the result is safe to keep. Skipping a step usually moves uncertainty forward rather than removing it.

The loop is deliberately small. You do not need a large specification or a long conversation for a one-file page. You do need enough detail to distinguish a correct result from a plausible-looking result.

Step 3

Build the Launch Checklist

The app has one job: let a user mark five launch checks and see the completed count update. It uses a single index.html file, with no packages, server, saved data, or network requests.

Why this is a useful first project

The checklist is small enough to understand in one sitting, but it still has real application behaviour. The HTML defines five controls and their labels. CSS makes the page readable and shows keyboard focus. JavaScript counts checked items, updates live status, and resets the interface. Testing touches structure, appearance, interaction, accessibility, and state.

The restrictions matter as much as the features. No package installation means there is no dependency tree to trust. No network call means the app cannot send its state elsewhere. No saved data means refresh is a predictable reset. One file means the learner can open the entire implementation and connect each requirement to a visible part of the source.

First ask for a plan

Inspect this empty practice folder. Do not create or edit files yet.

Plan a one-file Launch Checklist app for a beginner. It needs five labelled checkboxes, a live “0 of 5” completion count, a Reset button, visible keyboard focus, and a layout that works on a narrow phone. It must not save data or call the network.

Tell me which file you would create, how the controls will work, how you will test them, and any assumptions you are making.

Then approve the bounded build

Create the planned Launch Checklist in this folder as index.html.

Keep all HTML, CSS, and JavaScript in that one file. Use exactly five labelled checkboxes. Update the completed count after every checkbox change. Make Reset clear all checks and return focus to the first checkbox. Include an aria-live status, visible keyboard focus, and a mobile layout. Do not add packages, storage, analytics, external URLs, or network calls.

After building, test the five controls, count updates, Reset behaviour, focus return, mobile CSS, and absence of persistence or network calls. Report what changed and the exact test result.

Keep approval precise

Read the plan before sending the build prompt. It should name one file, the five behaviours, and the checks. If it proposes more, change the plan first. Approval should refer to the plan you actually read: “Proceed with that one-file plan. Do not add anything outside it.”

Codex may choose different names for JavaScript variables or a different visual style. Those choices are acceptable when the required behaviour, safety limits, and testability remain intact. The definition of done controls the result; cosmetic preference should not quietly replace it.

Read before accepting

What to look for in the Codex reply

Separate observation from assurance

“I added five checkboxes” is a change summary. “A source check found five checkbox elements” is an automated observation. “I clicked all five in Chrome and watched the count reach 5 of 5” is a browser observation. None of those statements alone proves the entire app is correct.

Ask for the exact command and output when Codex reports an automated pass. For browser work, ask which browser, viewport, and interactions it actually used. If Codex only read source, the honest result is “browser QA still required.” This distinction becomes important when a page looks correct but has a broken keyboard path, stale status, clipped mobile control, or console error.

Inspect the changed file

Open index.html and locate three parts. In the HTML, find the five checkbox inputs, their visible labels, the status, and the Reset button. In the CSS, find the focus rule and the narrow-screen media query. In the JavaScript, find the control list, the counting function, change listeners, and Reset listener. You do not need to memorise syntax. You should be able to point from each done criterion to the code that attempts to satisfy it.

Step 4

Test the result yourself

1. Open index.html in a browser. Confirm the count starts at 0 of 5.
2. Check each item once. Confirm the count moves through 1, 2, 3, 4, and 5.
3. Select Reset. Confirm all items clear, the count returns to 0, and focus returns to the first checkbox.
4. Use Tab and Space without a mouse. Confirm every control has visible focus and can be changed.
5. Narrow the browser to about 390 pixels. Confirm there is no horizontal page scroll or clipped control.
6. Refresh. Confirm the checklist returns to its initial state.

Record the result as you go

Run tests in a fresh state. If an early action changes the page, Reset or reload before the next independent check. That keeps one failure from confusing later observations. Do not edit while you are still collecting the first failure report; evidence is easier to trust when the starting point stays fixed.

What the automated test covers

The companion test reads the completed HTML, checks for exactly five controls, looks for the accessibility and mobile hooks, and rejects storage, fetch calls, and external URLs. It then runs the inline JavaScript against small stand-ins for the page controls. Those stand-ins let the test check 0, 1, and 5 completed items plus Reset and focus return without installing a browser test package.

That is useful evidence, but it cannot judge visual spacing, text clipping, actual keyboard focus appearance, or a browser-specific problem. The manual list fills those gaps. Good QA uses the smallest set of checks that covers the credible failures.

First-hand evidence

Compare the initial and completed states

Step 5

Practise one controlled failure

Use this as a hypothetical debugging exercise: imagine Reset clears the boxes but leaves the status at 5 of 5. A useful bug report separates what you expected from what happened.

Fix the smallest possible issue in index.html.

Expected: selecting Reset clears all five checkboxes, changes the status to “0 of 5 launch checks complete,” and returns focus to the first checkbox.

Actual in this practice scenario: the checkboxes clear, but the status still says “5 of 5.”

Reproduction: check all five items, then select Reset.

Inspect the current code, explain the cause, make only the needed change, and rerun the relevant tests. Do not add packages or change the design.

After the fix, repeat the exact reproduction steps. A passing test is evidence only for what that test covers.

Write a bug report Codex can act on

A useful report has four fields: expected behaviour, actual behaviour, exact reproduction steps, and the boundary on the fix. Add the first console error when one exists. Avoid reports such as “Reset is broken” or “the page looks weird”; they make Codex guess which state, control, viewport, or rule you mean.

The smallest-fix boundary protects working behaviour. For the practice failure, the visual design and checkbox clearing already work. A full rewrite would create more review work and more ways to break the page. Ask Codex to identify the cause, change only the responsible code, and rerun both the failing check and the nearby regression checks.

Distinguish cause from symptom

The stale number is the symptom. A missing call that recalculates the status after clearing might be the cause. Codex should inspect the current event flow before editing rather than assume. When it explains the cause, verify that the explanation matches the changed line and the reproduction steps.

If the first small fix fails, do not stack unrelated changes on top. Return to the last understood state, capture the new observation, and revise the hypothesis. Debugging is a sequence of measured checks, not a vote on which code looks most likely.

Review and recover

Finish by asking four questions

Read the final report against the brief

A strong report is short and specific. It names index.html, describes the count and Reset logic, lists the test command and observed pass, separates browser observations from source checks, and names any untested environment. It does not use confidence words in place of evidence.

When something remains uncertain, decide whether it blocks acceptance. An untested phone layout blocks a mobile-layout claim. An untested browser that your audience rarely uses may be a recorded follow-up rather than a blocker. The decision depends on the promised result and real use, not on a desire for perfect coverage.

Know the recovery level

Deletion is appropriate here because the project began empty and all work is contained in one disposable folder. A small existing project usually needs version control or a known-good copy. A production service needs a tested rollback, owner, timing window, and post-change checks. Never carry the beginner exercise’s delete-and-retry advice into a system where other work or data shares the same location.

Reusable tool

Build your next Plan, Build, and Review prompts

Write the facts once. This local form turns them into three prompts. It does not save or send what you type.

Use concrete nouns and observable results. “Improve my page” leaves the target open. “Add a five-item checklist whose count updates after each click” gives Codex something to inspect and test. Put current file names and audience facts in Context. Put forbidden actions and protected behaviour in Constraints. Put clicks, text, sizes, and test commands in Done criteria.

Knowledge check

Can you make the safe call?

Companion files

Use the beginner starter kit

The beginner starter kit puts the project brief, exact completed app, four copy-ready prompts, dependency-free tests, browser QA notes, two verified screenshots, and repository editing rules in one package. Use it to repeat the lesson or teach the same workflow without reconstructing the evidence.

A clean way to use the package

1. Read the brief without opening the completed app.
2. Copy the Plan prompt into Codex and compare its answer with the brief.
3. Approve only the bounded one-file build.
4. Run the supplied automated test against your result, then complete the browser checklist yourself.
5. Use the completed app and screenshots to investigate differences. A different colour or variable name is not a failure when behaviour and safety still match.
6. Read the repository editing rules before asking Codex to change the package itself.

The downloadable package separates reusable code from teaching material. The app, tests, workflow, and executable examples use the MIT License. Original prompts, prose, evidence, and owned screenshots use Creative Commons Attribution 4.0, so educators can adapt them with credit and a note describing changes.

Use the versioned download when you need a stable classroom or workshop reference. The source and evidence show exactly what was tested.

Continue learning

Choose the next guide for your goal

Method and sources

How this lesson was checked

The first-app reference file was inspected and tested locally. The two screenshots show only the initial 0-of-5 state and completed 5-of-5 state. They do not prove a Codex plan, keyboard test, or mobile test. Those checks are documented separately.

• Official ChatGPT quickstart
• Official Codex best practices
• Official Codex app documentation

Author: Curtis Pyke
First app last tested: 18 August 2026 · ChatGPT desktop app (Codex) and Chrome

FAQ

Common beginner questions