How to put Codex on your developer CV in 2026

What did OpenAI actually change about Codex in September 2026?

OpenAI expanded Codex on 29 September 2026 with reusable cloud development environments, a rebuilt command-line tool that accepts voice instructions, a code review experience inside the ChatGPT desktop app, and a security product that scans GitHub repositories and prepares fixes. That matters for your CV because the shape of the work changed, not only the tooling. Cloud environments keep task state — modified files, commands run, permissions granted — on the server rather than on the laptop that opened the session, so you can hand a task between devices. A team saves one approved configuration and everyone launches from the same base. Automatic reviews can produce a first pass on a pull request while you're away from your desk.

The security side is worth understanding before you write about it. Codex Security Cloud, in research preview at launch, scans connected GitHub repositories on demand, on a schedule, or whenever new commits land. It builds a repository-specific threat model, uses real code context, validates findings before they reach a human to cut noise, then ranks results with evidence and suggested patches. Access is tiered: reusable cloud environments and the voice CLI are included from Plus upward, while Security Cloud sits on the higher paid plans. OpenAI had already open-sourced a Codex Security CLI earlier in the year, so plenty of teams were scanning repositories before DevDay.

Here's the bridge to your job search. By 2026, hiring managers assume every engineer uses an assistant — that assumption is the baseline, not a differentiator. What the first screen actually tests is whether you can describe agent-assisted work with scope, ownership and outcomes attached. A recruiter spends somewhere between six and thirty seconds on the initial skim, and before that a parser has already flattened your file into text fields. So the CV job is narrow and specific: convert the work you did alongside an agent into claims a human can verify and a machine can read. The rest of this article is exactly how.

Should you list Codex on your developer CV at all?

Yes — once, in your skills section, and then only as the vehicle for results inside your bullets. Naming Codex on its own signals nothing in 2026, because the engineer you're competing with named it too. Here's the opinion I'll defend: a dedicated "AI tools" block listing six assistants actively hurts a senior CV. It reads as padding, it pushes your actual stack further down the page, and it invites the reviewer to assume the agent did the thinking. One line inside your existing tooling list — alongside your CI, your cloud and your observability stack — carries more weight than a proud little section of its own.

Codex earns real estate when you did something with it that another candidate probably didn't. Configuring and standardising reusable cloud environments for a team is infrastructure work. Triaging scanner findings, separating real vulnerabilities from noise and shipping the patches is security work. Wiring agent-assisted review into your pull request workflow, writing the repository guidance file that keeps the agent inside the lines, setting sandbox permissions, tuning what the agent may touch in CI — all of that is engineering judgement with a name and a result. If you're writing the whole CV from scratch around this, an AI CV builder will hold the structure while you supply the specifics.

Leave it off in three situations. First, on a junior CV where it would displace fundamentals — a hiring manager screening graduates wants to see you can read a stack trace without help. Second, where the employer is visibly cautious about agent-generated code in regulated or safety-critical work; save it for the interview and lead with testing and review discipline instead. Third, if listing it tips your CV into sounding machine-written, which reviewers now flag quickly. For the broader structure question of what a first screen actually rewards, our guide to a software engineer CV that passes the first screen covers the ordering in detail.

How do you write a Codex bullet that reads as evidence, not a tool list?

Name the outcome first, the mechanism second, the number third. "Used Codex for code review" is a tool list with a verb bolted on. "Cut median pull request review turnaround from 26 hours to 7 by adding an automated first-pass review across 40 repositories" is evidence — it survives a follow-up question, and it tells the reviewer what changed in the business. The agent belongs in the middle of the sentence, never at the front. Front position is reserved for what you owned. Any bullet that would still make sense if you swapped Codex for a different assistant is a bullet about you, which is exactly what you want.

Numbers make or break these bullets, and engineers routinely have better ones than they use. Review turnaround and queue depth. Findings triaged, false positives eliminated, mean time to patch. Environment setup time per new starter, which drops from hours to minutes when a team shares one saved configuration. Flaky tests removed, build minutes saved, incidents caused or avoided. Pick figures you could defend in a thirty-minute conversation, because you will be asked. If you genuinely don't have a metric, use scope instead — repository count, service count, team size, release cadence — and skip the invented percentage. Fabricated numbers are the fastest way to lose a technically literate interviewer.

Then cut the agent's share of the credit honestly. Senior reviewers are allergic to bullets implying an assistant shipped a platform migration for you. The strongest phrasing acknowledges the split: you defined the threat model, the scan produced ranked findings, you validated and merged the patches. That's an accurate division of labour and it reads as maturity. One more habit worth adopting — keep one bullet per role that shows what you did when the agent was wrong. Catching a plausible-looking patch that would have broken authentication is a better signal of engineering judgement than any throughput number on the page.

Which AI coding keywords belong in your 2026 skills section?

Use the words the job ad uses, in the form the ad uses them — that rule beats every keyword list anyone can hand you. In practice, 2026 engineering ads cluster around a predictable vocabulary: AI-assisted development, agentic workflows, code review automation, prompt engineering, LLM integration, RAG, vector databases, evaluations, guardrails, MCP, SAST and dependency scanning, secure code review. If the posting says "AI-assisted development", write that, not "AI-augmented coding". Parsers match strings, and human reviewers match habits of speech. Inventing a slicker synonym is how you disappear from a search that your experience should have won.

Structure matters as much as vocabulary. Keep one plain skills block with short labelled groups — Languages, Frameworks, Cloud and infrastructure, AI and developer tooling, Security — in a single column, comma-separated, no tables, no icons, no two-column layout, no text boxes. Multi-column CV templates are still the most common reason a genuinely strong engineering CV comes out of a parser as scrambled text. Spell out acronyms once where ambiguity is likely: "static application security testing (SAST)" gets you both matches. And put Codex where it belongs, inside developer tooling next to your CI and container stack, rather than in a standalone section that begs for attention.

Tailor per application rather than maintaining one master list that grows forever. The fastest honest method: paste the job description into your analysis alongside your CV and let the missing-skills output tell you which of your real experience you forgot to surface. For LinkedIn and Indeed postings, copy the text rather than the link, since both block automated fetching. Then rewrite only the skills and the top three bullets — the rest of the CV can hold. Twenty minutes per application, targeted, beats fifty generic sends, and the interview rate difference is not subtle.

How do you check your CV survives the first automated screen?

Run the file itself through a check, not the document you see in your editor — those are two different things. Export to PDF from a single-column layout, then confirm the extracted text still reads in the right order, that your dates parse, that your skills line survives intact and that nothing lives inside a header, footer, image or text box. HRLens's free CV analysis accepts PDF, Word or an image, returns a score out of 100 with five category scores — experience, tech stack, impact and ownership, clarity and structure, ATS compatibility — plus your strengths and a visual layout analysis, so you can see how the file actually lands.

For an engineering CV, the tech stack and impact and ownership scores are the two to watch. A high tech stack score with a low impact score is the classic AI-era failure mode: an impressive list of tools and agents, no evidence of anything shipped. That's precisely the gap this article exists to close, and it's visible in the scoring before a recruiter ever sees it. Add the job description to the analysis and you'll get the missing skills for that specific role, tailored suggestions, and ATS-friendly rewritten versions of your CV in six templates that mirror the posting's keywords. The full analysis, with the fix list, rejection reasons, blind spots, hiring probability and a salary estimate, is a paid upgrade at $3.99.

Then do the human check that no tool replaces. Read your top five bullets aloud. If a bullet doesn't tell you what changed, who it affected and roughly how much, rewrite it before you send anything. Ask a colleague who has actually interviewed engineers to spend sixty seconds on the first half-page and then tell you what you do — if they hesitate, your positioning is off, not your formatting. Codex, agents and whatever ships next quarter will keep moving. The part that doesn't move is this: a CV that proves you made specific things better, with numbers you can stand behind, gets the call.

Frequently asked questions