Codex 0.145.0 Safety Lab for QA Teams

Codex 0.145.0 safety lab is the new QASkills hands-on exercise I want every QA engineer to run before they trust AI-written test code. OpenAI’s 0.145.0 release adds stronger multi-agent, import, sandbox, MCP, and safety-buffer behavior, so the right question is not “can Codex write tests?” The useful question is: can your team review the tests with enough discipline to merge them safely?

Table of Contents

• Why This Codex 0.145.0 Safety Lab Exists
• What Changed in Codex 0.145.0
• Lab Setup: The Review Harness
• The Four Review Lanes
• Hands-On Playwright Example
• Rubric for SDET Teams
• India Context: What This Means for QA Careers
• Key Takeaways
• FAQ

Why This Codex 0.145.0 Safety Lab Exists

I see a pattern in test automation teams right now. Someone opens an AI coding agent, asks for Playwright or Selenium tests, gets a working-looking file, runs it once, and calls it productivity. That is not productivity. That is a faster way to accumulate test debt if nobody reviews the code for security, determinism, maintainability, and hidden assumptions.

The QASkills Codex 0.145.0 safety lab turns that vague concern into a practical exercise. Students get an intentionally imperfect AI-generated test suite. Their job is not to admire the output. Their job is to break it, review it, score it, and rewrite the weak parts until the test is safe enough for a pull request.

AI-written tests can look correct and still be unsafe

The biggest risk is not a syntax error. Syntax errors are obvious. The real risk is a test that passes for the wrong reason. I have seen AI-generated tests hard-code admin credentials, disable browser isolation, skip assertions after navigation, assert placeholder copy, swallow API errors, and overuse waits because the generated code is trying to make the demo pass instead of making the product safer.

That is why this lab is framed as a review exercise, not a prompt-writing contest. Prompting matters, but review habits matter more. A senior SDET must know how to inspect the output line by line and ask: what did the agent assume, what did it hide, and what will fail at 2 AM in CI?

QASkills turns the review into a repeatable drill

The lab has one simple promise: after 60 to 90 minutes, a tester should be able to review an AI-generated test PR with a checklist that works. The same checklist can be used for Codex, Claude Code, Cursor, GitHub Copilot, or any agent that edits files in a repo.

• Find unsafe test data and secret handling.
• Remove nondeterministic timing and environment assumptions.
• Refactor brittle selectors and duplicated setup.
• Document every assumption the agent made without evidence.
• Convert a flashy generated test into maintainable test code.

If you already follow ScrollTest, this fits next to our previous guides on AI coding agent testing, AI agent testing sprints, and release-impact cards for QA framework upgrades. The difference is that this post turns the release into a concrete training lab.

What Changed in Codex 0.145.0

The OpenAI Codex repository describes the tool as a lightweight coding agent that runs in the terminal, and its Codex 0.145.0 release notes were published on July 21, 2026. I do not treat release notes as marketing copy. I treat them as a QA input. Every new feature and every bug fix tells me what my team should test, what my review checklist should add, and what new failure modes may appear in our workflows.

Multi-agent and sub-agent behavior needs review discipline

Codex 0.145.0 stabilizes the opt-in multi-agent V2 experience with configurable sub-agent models, reasoning levels, concurrency, restored roles, and improved agent navigation. That is powerful, but concurrency changes the review surface. When multiple agents touch the same repo, a test author has to answer new questions:

1. Which agent wrote which file?
2. Did two agents modify the same fixture or helper with conflicting assumptions?
3. Does the final diff include all context needed for a reviewer?
4. Can the generated test be rerun from a clean checkout?
5. Did one agent add setup that another test silently depends on?

In the lab, students review a generated pull request where a sub-agent adds a helper that changes default timeouts globally. The tests pass locally, but the suite becomes slower and less predictable. That is the kind of issue a normal demo misses and a good QA review catches.

Importing settings increases migration risk

The release expands the /import flow to migrate Cursor and Claude Code settings, MCP servers, plugins, sessions, commands, and project-scoped memories. For productivity, that is useful. For enterprise QA, it is a risk area.

Imported memories and project settings can carry stale context into a new repo. An agent may remember an old staging URL, an old login command, or a team convention that does not apply anymore. The lab asks students to inspect a generated configuration file and decide what should be kept, what should be deleted, and what must be documented before the repo allows agentic changes.

Sandbox and safety-buffer changes affect test trust

The release notes also mention Windows sandbox reliability, network-proxy enforcement, and stronger safety and approval handling, including better forced-delete detection and preserved rejection reasons across tools. That is exactly the kind of change QA engineers should care about. If an agent can run commands, edit files, and propose test infrastructure changes, the safety layer is part of the product experience.

The lab connects this to secure development guidance from the NIST Secure Software Development Framework. NIST’s SSDF emphasizes secure practices across development, review, and release. For AI-generated test code, I translate that into a simple rule: generated code still needs human accountability before it enters the pipeline.

Lab Setup: The Review Harness

The Codex 0.145.0 safety lab uses a small Playwright project because Playwright makes failures easy to inspect through traces, screenshots, videos, and clean assertions. The same ideas apply to Selenium, Cypress, Appium, and API test suites. The tool is not the main point. The review habit is.

Repository structure

Students start with a repo that looks normal at first glance:

codex-safety-lab/
  package.json
  playwright.config.ts
  tests/
    checkout.spec.ts
    login.spec.ts
  fixtures/
    users.ts
  helpers/
    auth.ts
  review/
    checklist.md
    scorecard.md

The generated test suite includes enough good code to feel realistic. It also includes seeded problems: a hard-coded token, a flaky wait, a vague selector, an assertion that checks visibility without checking business outcome, and a helper that mutates shared state. The exercise is designed to train the eye.

The reviewer workflow

I prefer a three-pass review because it prevents shallow comments. Students must avoid the lazy review style where every comment says “LGTM” after one local run.

1. Pass 1: Run and observe. Execute the tests, capture failures, and inspect traces without editing code.
2. Pass 2: Read the diff. Review selectors, secrets, waits, fixtures, config, and assumptions.
3. Pass 3: Repair and prove. Rewrite weak parts, rerun from a clean environment, and attach evidence.

Commands used in the lab

The exercise keeps the command set small. A manual tester moving into AI-assisted automation should not need a 40-command setup to learn the review habit.

npm install
npx playwright install --with-deps
npx playwright test --trace on
npx playwright show-report
npx playwright test tests/checkout.spec.ts --repeat-each=5

The --repeat-each command is important. AI-generated tests often pass once because the browser state is lucky. Repetition exposes timing, data, and isolation issues. If a test cannot survive five clean reruns, I do not want it in a smoke suite.

The Four Review Lanes in the Codex 0.145.0 Safety Lab

The Codex 0.145.0 safety lab uses four review lanes: security, determinism, maintainability, and hidden assumptions. I like this framing because it avoids vague feedback. Every comment belongs to a lane, and every lane has a pass or fail signal.

Lane 1: Security

Security review starts with secrets, tokens, file access, network access, and destructive commands. AI coding agents can generate code that looks convenient but violates basic secure development practice. The OWASP Top 10 for Large Language Model Applications calls out risks such as prompt injection and insecure output handling. For QA teams, that means agent output should not be treated as safe because it compiles.

In the lab, students search for these red flags:

• Hard-coded credentials or tokens inside test files.
• Logs that print secrets, cookies, or bearer tokens.
• Tests that disable TLS checks without a documented local-only reason.
• Shell commands that delete files outside a scoped temp folder.
• Network calls to unknown domains added by generated helpers.

A secure rewrite moves credentials to environment variables, uses test-only accounts, masks logs, and scopes file writes. The reviewer must also check that the CI pipeline fails safely when required variables are missing.

Lane 2: Determinism

Determinism is where many AI-generated tests fail. The code may use waitForTimeout(5000), random test data without cleanup, shared accounts, or assumptions about test order. These are not small style issues. They decide whether the suite becomes a release gate or a source of Slack noise.

My rule is simple: a generated test should be able to run alone, run after another test, run in CI, and run five times without relying on leftover state. If that sounds strict, good. Smoke and regression tests deserve that level of discipline.

Lane 3: Maintainability

Maintainability review asks whether the next engineer can understand and change the test in six months. AI agents often produce long files because long code feels helpful. In a real framework, I want small helpers, clear fixture boundaries, readable names, and assertions tied to business behavior.

Common maintainability failures in the lab include duplicated login steps, selectors tied to CSS classes, helper names like doThing, and assertions that never explain the risk they cover. The repair is not fancy. Use page objects or screen objects when they reduce duplication, prefer user-facing selectors, and leave one comment only when it explains a domain rule.

Lane 4: Hidden assumptions

Hidden assumptions are the best part of the lab because they train senior thinking. The AI-generated code may assume that every user starts with an empty cart, every test runs in English, the checkout page is always enabled, or the app has the same feature flags in staging and CI. None of those assumptions are visible in the test name.

Students must add an assumption log to the PR. It can be short, but it must exist:

## Assumption Log
- Test account has checkout permission.
- Feature flag `new_checkout` is enabled in CI.
- Product SKU `qa-basic-plan` exists before test start.
- Payment provider runs in sandbox mode.
- Locale is locked to en-IN for this scenario.

Hands-On Playwright Example

The lab includes a before-and-after Playwright example. The bad version is not ridiculous. That is intentional. Real AI-generated code often has a mix of useful structure and dangerous shortcuts.

Generated version: passes locally, weak in CI

import { test, expect } from '@playwright/test';

test('user can checkout', async ({ page }) => {
  await page.goto('https://staging.example.com/login');
  await page.fill('#email', 'admin@example.com');
  await page.fill('#password', 'Password123');
  await page.click('button');
  await page.waitForTimeout(5000);

  await page.goto('https://staging.example.com/products');
  await page.click('.product-card:first-child .buy');
  await page.click('text=Checkout');
  await expect(page.locator('.success')).toBeVisible();
});

This test has obvious problems once you know what to look for. It hard-codes credentials. It uses a raw staging URL. It clicks the first product without controlling test data. It waits for five seconds instead of waiting for a real condition. It checks a generic success element without verifying order details.

Reviewed version: safer and more deterministic

import { test, expect } from '@playwright/test';

const baseURL = process.env.STAGING_BASE_URL;
const email = process.env.CHECKOUT_TEST_EMAIL;
const password = process.env.CHECKOUT_TEST_PASSWORD;

test.describe('checkout smoke', () => {
  test.beforeEach(async () => {
    expect(baseURL, 'STAGING_BASE_URL is required').toBeTruthy();
    expect(email, 'CHECKOUT_TEST_EMAIL is required').toBeTruthy();
    expect(password, 'CHECKOUT_TEST_PASSWORD is required').toBeTruthy();
  });

  test('paid test user can place sandbox order', async ({ page }) => {
    await page.goto(`${baseURL}/login`);
    await page.getByLabel('Email').fill(email!);
    await page.getByLabel('Password').fill(password!);
    await page.getByRole('button', { name: 'Sign in' }).click();

    await expect(page.getByRole('heading', { name: 'Products' })).toBeVisible();
    await page.getByTestId('product-qa-basic-plan').getByRole('button', { name: 'Buy' }).click();
    await page.getByRole('link', { name: 'Checkout' }).click();

    await expect(page.getByRole('heading', { name: 'Order confirmed' })).toBeVisible();
    await expect(page.getByTestId('order-plan-name')).toHaveText('QA Basic Plan');
  });
});

This version is not perfect, but it is reviewable. It makes environment dependencies explicit. It uses user-facing selectors and test IDs where the business object needs a stable reference. It asserts the actual checkout outcome. Most important, it fails with a clear reason when CI is not configured correctly.

Review comment examples

• Weak: “This looks flaky.”
• Better: “Replace waitForTimeout(5000) with an assertion on the Products heading so the test waits for app readiness, not wall-clock time.”
• Weak: “Use better selectors.”
• Better: “Do not click .product-card:first-child. Pick a seeded SKU so the scenario checks the intended product.”
• Weak: “Secrets issue.”
• Better: “Move email and password to CI secrets and fail fast when they are missing. Do not commit reusable credentials.”

Rubric for SDET Teams

A lab is useful only if teams can repeat it. The QASkills Codex 0.145.0 safety lab includes a 100-point rubric that a lead can use in bootcamps, internal onboarding, or weekly QA guild sessions.

The 100-point scorecard

Area	Points	Pass signal
Security	25	No committed secrets, scoped commands, safe logging, clear CI secret handling
Determinism	25	No fixed sleeps, isolated data, repeatable from clean checkout
Maintainability	25	Readable names, stable selectors, minimal duplication, useful abstractions
Hidden assumptions	25	Assumptions listed, feature flags documented, environment constraints explicit

I set 80 as the minimum pass score. Below 80, the student must repair the test and resubmit. Above 90, the student explains which review habit caught the highest-risk issue. That reflection matters because the goal is judgment, not just a green run.

How managers can run it in one sprint

If you manage a QA team, you do not need a large program to start. Run it as a two-session sprint:

1. Day 1, 60 minutes: Explain the four lanes, assign the generated PR, and ask each engineer to submit review comments.
2. Day 2, 90 minutes: Pair engineers, repair the suite, run the evidence commands, and compare scorecards.
3. Day 3, 30 minutes: Convert the best comments into your team’s AI-generated code review checklist.

This is lightweight enough for service companies and product companies. In TCS, Infosys, Wipro, or Accenture style delivery teams, the lab can fit into a Friday learning hour. In product companies, it can become part of the merge policy for AI-authored test changes.

Where it connects with release-impact cards

I like pairing this lab with release-impact cards. Codex 0.145.0 is a release. The safety lab is the response. For every major agent or framework release, a QA lead should ask four questions:

• What new capability can change how tests are generated?
• What new failure mode can enter the workflow?
• What checklist needs an update?
• What evidence should a reviewer request before merge?

India Context: What This Means for QA Careers

For Indian QA engineers, the Codex 0.145.0 safety lab is more than a product update. It is a career signal. Many manual testers and automation engineers are trying to decide what AI means for their role. My answer is blunt: the value shifts from writing every line by hand to reviewing, constraining, and proving AI-generated work.

Service-company testers need review muscle

In large service companies, teams often inherit client frameworks with strict process, legacy selectors, and fragile environments. AI coding agents can produce code quickly, but client delivery still needs traceability. A tester who can say “I reviewed this generated PR across security, determinism, maintainability, and assumptions” is more useful than someone who only says “I used AI to generate tests.”

This is especially relevant for testers moving from manual QA into SDET roles. If you can combine domain testing with AI code review, you create a practical bridge. You do not need to become a compiler engineer. You do need to understand test isolation, CI behavior, data setup, selectors, and failure evidence.

Product-company SDETs need merge standards

In product companies, the bar is different. The test suite is not just documentation. It gates releases. If AI-generated tests increase flakiness, every deployment pays the cost. A strong SDET can introduce an agent workflow without lowering merge standards.

That is the career angle I would bet on. The next ₹25-40 LPA SDET roles will not reward people for blindly pasting prompts. They will reward engineers who can design agent-safe workflows, review generated code, write deterministic tests, and keep CI trustworthy.

Portfolio idea for learners

If you are building a QA portfolio, add a small “AI-generated test review” project. Do not show only the final code. Show the review trail:

• The original generated test file.
• Your review comments grouped by the four lanes.
• The repaired test file.
• A Playwright trace or report from repeated runs.
• A short markdown scorecard explaining what changed and why.

Key Takeaways

The Codex 0.145.0 safety lab is built around one practical idea: AI-generated test code should pass a stronger review, not a weaker one. The release adds useful Codex capabilities, but QA teams still own the quality of what gets merged.

• Codex 0.145.0 introduces changes around multi-agent workflows, imports, MCP startup, sandbox reliability, and safety handling that QA teams should review as release-impact signals.
• A generated test that passes once is not enough. It must be secure, deterministic, maintainable, and explicit about assumptions.
• Playwright traces, repeated runs, and clear PR comments turn AI code review into evidence, not opinion.
• Managers can run this as a two-session lab and convert the output into a team checklist.
• For SDETs in India, AI code review is becoming a valuable skill because it combines automation knowledge with release ownership.

FAQ

What is the focus of the Codex 0.145.0 safety lab?

The lab teaches QA engineers to review AI-generated test code for security, determinism, maintainability, and hidden assumptions. It uses the Codex 0.145.0 release as the trigger, but the checklist works for most coding agents.

Do I need Codex installed to learn from the lab?

No. Codex helps if you want to reproduce the agent workflow, but the main exercise is reviewing generated code. You can run the same review against output from Cursor, Claude Code, GitHub Copilot, or another agent.

Why use Playwright for the examples?

Playwright gives clear assertions, trace files, and repeatable command-line workflows. That makes it easier to show why a generated test passed, failed, or became flaky. The same review lanes apply to Selenium and Cypress.