Your team ships with Codex, and every engineer works the same way.

How the training runs in Codex

hackers&wizards runs Codex training for engineering teams as an in-house team training: two days, remote or on site across Germany, Austria and Switzerland, in German or English, then mentoring while your team applies it to real work. It is our Agentic Engineering for Developers and QA training, run in Codex.

EUR 1,500 per participant. Team training, EUR 15,000 at most for the two days: up to 12 people attend, and you pay for 10 at most. Net, plus VAT. On site, plus travel at cost.

Teams have run every one of our trainings for engineering, product and leadership in Codex. Exercises, review steps and mentoring work the same way in every agent. What changes are the instruction files and the settings, and we set those up with you on day one.

What changes in Codex

After the training, your team keeps one instruction file that Codex and Claude Code both read, and picks the sandbox and approval settings each task needs.

• AGENTS.md holds the rules

  Codex reads AGENTS.md from the repository root down to the folder it works in, one file per folder, and stops adding text at 32 KiB by default. Where a folder has no AGENTS.md, Codex reads the names listed in project_doc_fallback_filenames, so a repository that keeps its rules in CLAUDE.md lists it there and Claude Code and Codex read the same file.

• Skills and custom agents live in the repository

  Skills are folders under .agents/skills, each with a SKILL.md. Custom agents are TOML files under .codex/agents with a name, a description and developer instructions, so the review agent your team writes on day one is versioned with the code.

• Hooks and MCP sit in config.toml

  Hooks run on events such as PreToolUse and Stop, configured in .codex/hooks.json or config.toml. MCP servers are [mcp_servers] tables, added by hand or with codex mcp add. A project's .codex/config.toml applies to trusted projects only.

• Sandbox and approvals are two settings

  The sandbox decides what Codex can touch: read-only, workspace-write or danger-full-access. The approval policy decides when it asks: on-request, never, or granular per category. For a trusted Git repository Codex recommends Auto, workspace-write with on-request approvals, with network access off. --yolo drops both.

What you set up on your side

• Codex on every participant's machine: the CLI, the IDE extension or the desktop app, signed in through your ChatGPT Business or Enterprise workspace or with an API key. Codex cloud needs the ChatGPT sign-in.
• Our hosted training environment runs Claude Code, so a Codex training runs on your machines and licences. Your code stays there: the trainer works with your team on screen.
• In the preparation call we agree which sandbox and approval settings your security team allows, and which repository the team practises on: one of ours or your own.

That way your team spends day one in Codex with settings your security team has already approved.

Example: day one in Codex

By the end of the day, your team has an AGENTS.md cut to what Codex needs, approvals set from its own notes and a review agent that checks changes before the pull request.

This is how the first day typically runs in Codex. Your trainer cuts it to your codebase in the preparation call.

• Write the AGENTS.md a new colleague would need

  The team has Codex draft AGENTS.md from the codebase, then cuts it to build and test commands, conventions and the folders nobody touches. The typical mistake is a file that repeats the README. The team deletes every line Codex could read from the code itself, adds a nested AGENTS.md in one subfolder and has Codex, started there, say which rules it follows.

• Start in Auto and widen on evidence

  Participants work in Auto and note every approval Codex asks for. After an hour the team decides what it really needs, for example network access for the package manager, and sets that in config.toml. --yolo stays for throwaway containers.

• A second reviewer before the pull request

  One session builds a small feature, then the team asks Codex to hand the diff to a custom agent from .codex/agents, which reviews it against AGENTS.md and lists real issues only. Teams running Claude Code next to Codex let each agent review the other's changes, as our own training repositories do with codex exec.

What stays the same

The practice is the same in every agent: how the agent loop works, what context it needs, how to delegate so it checks its own work, and how the whole team keeps one way of working. The agenda, the trainers and the mentoring are those of the training you book.

Questions before you book

Sources

Vendor facts on this page, checked against the vendor's documentation on 27 October 2026.