,

Open coding features and first project

16 min read
Featured image: First Codex project

It is 5:15 p.m. The ticket says “small README fix.” You open the ChatGPT desktop app the way you always do for drafts and status decks. Someone on the team said Codex would handle the repo. You paste the repo path into a normal Chat thread. The model invents a folder layout that does not exist. You paste a second time with more context. Now you have three conflicting answers and zero git history. The problem was not the model. You used the office door for a software job.

This is Part 1 of the ChatGPT Codex tutorial. Codex is OpenAI’s coding agent surface for software work: projects, local files, terminals, diffs, and reviewable changes. On desktop it sits next to Chat and Work in the merged ChatGPT app. If orientation still feels fuzzy (accounts, plans, memory, first-week safety), start with Learn ChatGPT from scratch. If Chat vs Work vs Codex still blur in a standup, keep the ChatGPT product map open. Everyday writing and planning without agent blast radius live in the ChatGPT everyday tutorial. Multi-step office deliverables (decks, sheets, docs) live in the ChatGPT Work tutorial. Here we open coding features, pick a first project, and survive the first honest loop: orient, tiny change, review.

UI labels, plan packaging, and which surface gets which feature still move. Treat names and rollout notes below as a July 2026 field guide. Re-check chatgpt.com/codex, Using Codex with your ChatGPT plan, ChatGPT Work and Codex, and developers.openai.com/codex the week you write team policy or buy seats.

What you’ll learn

  • A plain definition of Codex as the coding agent surface in ChatGPT (not Chat, not Work)
  • Where Codex shows up: desktop app mode, plus related editor, CLI, and web paths as the product offers them
  • How Free/Go vs Plus/Pro (and team plans) shape usage, without inventing exact quotas
  • What you need before first project open: sandbox folder, branch, secrets hygiene, policy clarity
  • A first-run ritual: open project, ask orientation, one tiny safe change, review the diff
  • What Codex is good at and what it is not for on day one
  • Common mistakes that waste limits or land unreviewable patches
  • What Part 2 will make concrete: exploring a repo safely before you edit

Codex in one sentence

Codex is the agent-shaped coding surface in ChatGPT for software development and technical work. You open a project (local repo, related tools, developer context). You ask it to read, plan, edit, run commands, and produce changes you can review. You stay responsible for what gets committed, merged, and deployed.

That is different from Chat. Chat is conversational assistance: you ask, you get a reply, you leave. You remain the operating system for every paste. Work is different too. Work is multi-step office work toward finished-looking deliverables such as decks, sheets, and docs. Codex is software in a project tree: code, tests, diffs, pull-request style review. Same login family. Different job type.

Rule of thumb: Chat answers and drafts with you. Work runs multi-step office jobs toward a package you still check. Codex changes software under review. Pick by the artifact you need when you are done.

Where Codex sits next to Chat and Work: Chat for words, Work for office agent deliverables, Codex for the code agent
Where Codex sits next to Chat and Work: Chat for words, Work for office agent deliverables, Codex for the code agent

Why Codex exists at all

For years, “I used ChatGPT for code” meant paste a function into Chat, get a rewrite, paste it back, hope you did not miss a call site. That works for a ten-line helper. Real repos are messier. Entry points hide under monorepo packages. Tests name behaviors the README forgot. Auth lives three folders away from the form that fails. In Chat, you become the glue. You re-paste context. You lose track of which version of the file was last true.

Codex exists because software work wants a different loop: project context, plan, tools, edits, checks, reviewable diff. OpenAI’s product language is blunt about the split. Chat stays for fast conversational help. Work stays for longer multi-step office work and finished deliverables. Codex stays dedicated to software development and technical work. Help articles describe ChatGPT desktop as Chat and Work under ChatGPT, plus Codex alongside them on macOS and Windows.

At work, vocabulary costs money. Finance may approve a Plus seat and still be shocked when agent coding sessions burn capacity. IT may allow browser Chat and still restrict local folder access. An analyst who only knows Chat will paste stack traces into a thread while an engineer expects a project with diffs. Name the mode. Plans, permissions, and review habits become discussable once the door has a name.

Where Codex shows up

As of mid-2026, the ChatGPT desktop app is where OpenAI made the three-way split hardest to ignore. Chat, Work, and Codex live together in one install on Mac and Windows. That matters for muscle memory: you open one app, then you choose a job type, not a separate brand for every task. Official help describes a clearer desktop layout with a switcher between ChatGPT and Codex, and product notes that Codex remains a dedicated software surface even as the apps merge.

Codex is not only “a button in the desktop app.” OpenAI also documents Codex across related surfaces connected by your ChatGPT account: the desktop Codex mode, IDE extension, CLI, web/cloud-style workflows, and GitHub-oriented paths depending on your plan and setup. Treat “same agent family, different harness” as the mental model. Day-one learning still starts best on desktop Codex with a local project you can see and undo.

Desktop: deepest first-week home

Desktop is the right home when local files, terminals, diffs, and side-by-side review matter. If the only clean copy of the repo is on your laptop, plan on desktop. If you need to sit beside an editor window and watch the agent propose hunks, desktop is built for that friction. Confirm which account is signed in before you grant folders. Personal login on a company monorepo is how security tickets are born.

Editor, CLI, and web: later, not required tonight

Once the desktop loop feels honest (orient, change, review), add the surface that matches your daily tools. Some people live in an IDE extension. Some prefer a terminal CLI. Some teams lean on cloud agents for longer jobs. None of those replace the habit of reading the diff. If you skip desktop and jump straight into a long unattended cloud run on day one, you are practicing courage, not craft.

SurfaceBest for early learningWatch-out
ChatGPT desktop (Codex mode)First project open, local files, visible progress, side-by-side with Chat/WorkUpdate the app; confirm account; grant only folders you mean
IDE extensionPeople who already live in the editor and want agent help next to the cursorStill review diffs; do not treat autocomplete theater as a merge plan
CLITerminal-first workflows, scripts, SSH-friendly environmentsPermissions and shell risk; read prompts before you allow commands
Web / cloud-style CodexLonger jobs, parallel agents, team workflows as your plan allowsNot a free pass to skip review; not silent production deploy

Plans and limits without inventing quotas

OpenAI’s help copy is clear on the shape, even when exact numbers move: Codex is included across ChatGPT plans, including Free and Go, with usage limits that vary by plan. Plus and Pro get more usable coding time for focused sessions and fuller workdays. Business, Enterprise, Edu, and related org plans add admin controls and team packaging. Some Plus and Pro users can add credits when they hit included limits. Other users may need to upgrade or wait for a reset. Re-check chatgpt.com/pricing and the live Codex rate card before you promise capacity to a team.

Practical translation for Part 1:

  • Free / Go: enough to learn the shape of Codex and try a tiny safe change if the product exposes it on your account. Not the place to burn a week of monorepo refactors.
  • Plus / Pro: the usual home for real personal coding sessions; still finite. Scope before you start.
  • Team / Business / Enterprise: admin policy, shared norms, and often clearer answers about what folders and connectors are allowed.

Agentic coding burns more than a short Chat rewrite. That is normal. Scope is a budget skill, not a personality flaw.

What you need before the first project

Codex works on real project folders. It is not a second Chat thread with a darker theme. You will get more out of first run if five things are true.

  • A project directory you are allowed to open. Prefer a personal sandbox or a throwaway clone over production on day one. If the only copy is the live deploy repo, clone again into a practice folder.
  • An account path that includes Codex access on your plan. Sign in with the ChatGPT account you intend to use for this machine. Confirm Free/Go limits vs Plus/Pro capacity on the live pricing page, not on a blog rumor.
  • Git on the machine (strongly recommended). Branch before edits. Diff after edits. Undo without archaeology. You can learn without perfect git habits, but “review the diff before commit” is much easier when git exists.
  • Secrets hygiene. No production API keys, no customer dumps, no .env contents pasted into chat “just this once.” Point the agent at code structure, not at live credentials. Use placeholders and local env files that stay out of the conversation log.
  • Company policy clarity if this is work code. Personal keys in a corporate monorepo create tickets. If policy is silent, ask before the first PR. If policy bans local agents on certain repos, respect that even if the tool is impressive.

Open coding features: the first five minutes

Exact menu labels move. The job sequence stays stable:

  1. Update and open the ChatGPT desktop app.
  2. Sign in with the correct account.
  3. Switch into Codex (not Chat, not Work). Official help frames desktop as Chat and Work under ChatGPT, with Codex as the software surface alongside.
  4. Open or attach a project: a local repository folder you own or are allowed to touch.
  5. Confirm folder permissions: grant the project root, not your entire home directory, unless you have a real reason.

If the app still looks like “only Chat,” update it, check release notes for your plan, and confirm you are not on a surface that has not received the merged layout yet. Enterprise rollouts can lag consumer screenshots. Do not invent features from a marketing page your tenant does not have.

Create a branch before you invite edits

In a terminal next to Codex (or with git habits you already trust):

cd ~/src/notes-sandbox
git status
git checkout -b practice/codex-first-run

If the working tree is dirty, stop. Commit or stash your own work first. Do not let an agent’s first session land on top of half-finished personal edits you cannot separate later.

The first project ritual

Open Codex and first project flow: desktop Codex mode, open or clone repo, ask what this does, tiny safe change, review the diff
Open Codex and first project flow: desktop Codex mode, open or clone repo, ask what this does, tiny safe change, revi…

People fail first run by asking for a rewrite of auth on minute two. The ritual is smaller and boring on purpose.

Step 1: open the project

Use a small repo you can afford to mess up. Ideal: a personal side project, a tutorial app, or a fresh clone of something you already understand at a high level. Avoid: production deploy configs, customer data, and monorepos where one bad command touches twenty packages.

Step 2: ask orientation questions (no edits yet)

Type questions that force a map with paths, not vibes:

What does this project do?
Where is the main entry point?
How do I run tests and start the app locally? Quote commands from the repo if they exist.
Do not edit any files yet.

Open the files it cites. If the entry path is wrong, say so and ask again. You are calibrating the agent against the tree, not grading a book report.

Step 3: one tiny safe change

Pick something reversible and reviewable in under two minutes of reading. Examples:

  • Fix a typo in the README
  • Add a one-line comment next to an existing helper (if your team allows comments that teach)
  • Tighten an error message string that already has a test nearby
  • Add a missing badge line that is already documented elsewhere

Phrase the ask like a ticket for a careful teammate:

In README.md only, fix the typo "instalation" to "installation".
Do not change any other files.
Do not reformat the whole document.
Show the diff and wait for me to review before any commit.

Step 4: review the diff (non-negotiable)

After the agent edits, read the change. Prefer both the in-app diff and your own git view:

git status
git diff

Look for:

  • Files you did not mention
  • Formatting churn that hides a real logic change
  • Deleted tests or weakened assertions
  • New dependencies you did not approve
  • Secrets, tokens, or .env contents that should never appear

Commit only when you can defend the patch in one sentence. If the agent drafts a commit message, rewrite anything you could not say out loud in standup. Later parts of this series go deeper on review and tests. The habit starts now: no blind commits, no silent production deploys.

Worked example: README typo on a notes sandbox

Setup: you cloned notes-sandbox into ~/src/notes-sandbox, created branch practice/codex-first-run, and opened that folder in desktop Codex.

Orientation

I am new to this repo. Prefer small diffs.
What does this project do?
Where is the HTTP entry point?
How do I run tests?
Do not edit files yet.

Codex points at src/server.js, src/routes/notes.js, and package.json scripts. You open those paths. They match. Good. You also notice README says “instalation” in the setup section. That is your tiny change.

Tiny change

Fix the typo "instalation" to "installation" in README.md only.
Do not touch source files.
Do not reformat other sections.

The agent proposes a one-line edit. You approve after reading the path. You run:

git diff README.md

One line. No surprise lockfile. You commit: “docs: fix installation typo in README.” That loop is small on purpose. If you cannot complete a tiny loop honestly, you are not ready for a multi-file refactor.

What Codex is good at (early)

Codex earns its keep when the job is software-shaped and you will review the result:

  • Explaining an unfamiliar folder tree with file paths
  • Locating entry points, tests, and config
  • Drafting small patches that match existing patterns
  • Running allowed local commands (tests, linters) under your watch
  • Producing diffs you can accept, reject, or edit

It is less magical when the tree is huge, the ticket is vague, secrets sit in the prompt, or nobody will read the diff. Speed without review is how “AI wrote it” becomes an incident report.

What Codex is not for (especially day one)

Wrong jobBetter doorWhy
One-line email rewriteChatNo project tree, no agent needed
Status deck from notes and a sheetWorkOffice deliverable, not software patch
Silent production deployYour release process + humansAgents do not own uptime or blame
Paste production secrets “for context”Redacted examples / local env onlyChat logs are not a vault
Whole monorepo rewrite before a mapExplore first (Part 2)You cannot review what you cannot explain

Safety rails that are not optional

Explore before edit (preview of Part 2)

If you do not know where auth lives, do not ask for a rewrite of auth. Ask for a map. Demand paths. Open files. Part 2 is the full explore playbook. The rule starts in Part 1: orientation before ambition.

Branch early

A named branch turns “the agent did something weird” into “reset this branch.” Working on main with live deploy hooks is how a practice session becomes a pager alert.

No secrets in chat

Do not paste .env contents, private keys, customer PII, or session cookies “so the agent can debug faster.” Describe the shape of the config. Use dummy values. If a log already contains a secret, rotate it; do not paste more of it into the model.

Not for silent production deploys

Codex can help write and test changes. It does not replace your release checklist, change advisory board, or the human who owns the outage. Treat any suggestion that force-pushes to production, disables tests, or skips review as a smell. Later posts cover review and git habits in more depth. The red line is already here: no unattended production deploys.

Parallel ideas, OpenAI product names

If you have used other coding agents (for example Claude Code in a terminal), the good habits transfer: map before edit, small diffs, human review, tests as seatbelts. The product names and surfaces do not transfer one-for-one. On the OpenAI side, say Codex for the coding agent, Chat for conversation, Work for office multi-step jobs. Do not call every agent “Copilot” or every desktop mode “ChatGPT Code” in a ticket. Shared language is how teams write policies that survive a reorg.

Common mistakes

Using Chat for a repo job

Paste-driven coding in Chat loses project context and creates untracked edits outside git. Open Codex. Attach the project.

Opening Work for a software patch

Work is great for a deck about the release. It is the wrong door for changing the release pipeline code.

Skipping orientation

“Rewrite billing” on a cold tree produces confident wrongness. Ask what the project does and where the entry point is first.

Granting the whole home directory

Grant the project root. Broader access multiplies blast radius if a command runs somewhere you did not intend.

Committing without reading the diff

Pretty explanations are not the patch. The hunks are the patch. Read them.

Burning Free/Go limits on a rewrite epic

Learn the loop with a tiny change. Scale ambition with plan capacity and review skill together.

Pasting secrets “just for this debug”

There is no safe “just this once” for production credentials in a chat log.

How this series fits the AMS ChatGPT path

On Analytics Made Simple, ChatGPT learning is a ladder, not a pile of random tips:

  • Learn ChatGPT from scratch: what it is, plans, first minutes, modes overview, memory, multimodal, connectors, judgment
  • ChatGPT product map: Chat vs Work vs Codex, Custom GPTs, models, light API notes
  • ChatGPT everyday tutorial: writing, planning, learning, long docs, email and workplace writing without agent blast radius
  • ChatGPT Work tutorial: multi-step office jobs, approvals, checkpoints, when Work beats Chat
  • ChatGPT Codex tutorial (you are here): coding features, safe explore, skills/tasks as offered, review and tests, git-friendly habits
  • Later: Custom GPTs tutorial

If you skipped straight here from a marketing page, that is fine. Bookmark Learn and the product map so you do not invent policy from demos. Wider curriculum paths also sit on Learn.

Practice for this week

Do not start with production billing. Do this instead:

  1. Update ChatGPT desktop and confirm you can switch into Codex.
  2. Clone or open a sandbox repo you own. Create a practice branch.
  3. Ask orientation questions with “do not edit yet.” Open the paths it cites.
  4. Request one tiny safe change (README typo level). Review git diff.
  5. Commit only if the patch is defensible. Note your plan limits if you hit them.
  6. Stop before a multi-file rewrite. Part 2 is exploring a repo safely.

Quick recap

  • Codex is the coding agent surface in ChatGPT for software work you still review
  • Chat is conversation; Work is office packages; Codex is code under review
  • Desktop merges Chat, Work, and Codex; related IDE/CLI/web surfaces share the account family
  • Free/Go can learn the shape; Plus/Pro usually carry day-to-day coding usage; re-check live limits
  • First ritual: open project, orient, tiny change, review diff
  • Branch first; keep secrets out of chat; no silent production deploys
  • Next: explore a repo safely (Part 2)

What’s next

Part 2: Exploring a repo safely turns orientation into a full map: good first questions, bounds on what not to touch, explore-before-edit discipline, and a worked loop you can run on any unfamiliar codebase this week. After that, skills and tasks as the product offers them, review and tests without trusting green checkmarks alone, then git-friendly habits for beginners.

Sources

Official product and help materials used for this article (re-check the week you set policy; UI and plan packaging move):