D3 · Extending and Configuring Codex

This domain is worth 20% of the mock — roughly 10 of 50 items. It tests whether you can configure Codex safely and extend it deliberately: the shared config.toml and AGENTS.md, the extension points (skills, plugins, MCP, hooks), and above all the safety surface — permission modes and profiles, sandboxing, auto-review and internet-access controls. Many items reward the safe configuration, not the most permissive one.

What you need to know

One shared config.toml configures the desktop app, CLI and IDE extension; AGENTS.md carries per-repository agent guidance, and rules and subagents shape behaviour. Codex is extended through skills, plugins, MCP servers, hooks, record & replay, and site tools (WebMCP). Its safety surface is where the exam concentrates: permission modes and profiles, sandboxing (including Windows sandbox and WSL), auto-review of diffs, and cloud internet access controls. There is also an opt-in experimental context management feature with specific sign-in limits.

Learning objectives

By the end of this page you should be able to:

1. Configure Codex through the shared config.toml and per-repo AGENTS.md, rules and subagents.
2. Extend Codex with skills, plugins, MCP servers and hooks, and know what each adds.
3. Choose permission modes and profiles appropriate to the risk of a task.
4. Apply sandboxing — including Windows sandbox and WSL — to contain what Codex can do.
5. Use auto-review and cloud internet-access controls as part of a safe workflow.
6. Explain experimental context management and its sign-in limits.

3.1 The shared config.toml

One configuration file serves the desktop app, the CLI and the IDE extension. Set the model, and reference the config basics/advanced/reference docs, environment variables and the sample config for the full surface.

# config.toml — shared by desktop app, CLI and IDE extension
model = "gpt-5.6"

[features]
# opt-in features live here (see 3.7)

3.2 AGENTS.md, rules and subagents

Agent configuration shapes how Codex works in a given repository.

• AGENTS.md — the durable, checked-in guidance: build/test commands, conventions, no-go areas (covered in D2).
• Rules — behavioural constraints that steer or forbid actions.
• Subagents — delegation of parts of a task to parallel agents (the mechanism behind the Ultra reasoning level).
• Speed — configuration that trades latency against thoroughness.

config.toml         AGENTS.md            rules            subagents
(machine/           (per-repo            (behavioural     (parallel
 workspace          build, conventions,   constraints)     delegation)
 defaults)          no-go areas)
     └───────── how Codex is set up ──────────┘   └── how work is split ──┘

3.3 Extending Codex: skills, plugins, MCP, hooks, record & replay

Codex has several distinct extension points; the exam expects you to tell them apart.

3.4 Permission modes and profiles

Permission modes govern what Codex may do without asking. Profiles bundle settings for a context (personal, team, CI). This is the highest-value safety lever in the domain.

LESS PERMISSIVE ───────────────────────────────► MORE PERMISSIVE
ask before every         auto-approve reads,        broad auto-approve
sensitive action         prompt on writes /         (only in a trusted,
(read-only leaning)      network / escalation       sandboxed context)

Match the mode to the RISK of the task, not to convenience.

• Use a restrictive mode for unattended runs (codex exec in CI) so an agent cannot escalate silently.
• Use profiles to keep a safe default for shared machines and a looser one only inside a sandbox.
• Approvals are the human decision point for escalations — treat them as a review gate, not a nuisance.

3.5 Sandboxing, including Windows sandbox and WSL

Sandboxing contains what Codex can touch — the filesystem, the network, the shell. Environments include local, cloud and git worktrees; on Windows, the Windows sandbox and WSL are supported.

3.6 Auto-review and cloud internet access

Two features complete the safe-workflow picture.

• Auto-review — Codex reviews the diff it produced and surfaces a summary you can attach as reviewer evidence (see D2 §2.6). It is an aid to review, not a replacement for a human reviewer.
• Cloud internet access controls — govern whether a cloud run can reach the network. Default to no or restricted access; open it deliberately when a task genuinely needs it (e.g., fetching a dependency), and remember the data-handling implications.

Diff produced ─► AUTO-REVIEW summary ─► attach as evidence ─► HUMAN review ─► merge
                 (agent's own read;        (D2 §2.6)          (still required)
                  not a substitute)

3.7 Experimental context management

Astra can keep notes across context windows and search earlier messages and tool results within the same task. This is experimental and opt-in.

[features.context_management]
experimental_mode = true

Sign-in limits matter: at launch it is available on ChatGPT Plus/Pro sign-in only — not Business, Enterprise or API-key sign-in. So an enterprise team on a Business/Enterprise workspace cannot rely on it yet, and an item that offers it as the fix for an enterprise team is wrong on availability alone.

Decision framework

Use CONFIGURE → CONTAIN → EXTEND → REVIEW (CCER) when setting Codex up for a task or team.

Common mistakes

Scenario challenge

Scenario. A fintech team wants Codex to run a nightly job that upgrades dependencies and opens a PR. They also want the agent to “keep notes across the long task so it does not lose context”, and they run on a ChatGPT Enterprise workspace. An engineer proposes: broad auto-approve so the job never stalls, full cloud internet access, experimental context management turned on, and auto-review as the only review before the PR merges automatically.

Expert reasoning trace.

1. Permission mode is wrong. Broad auto-approve on an unattended nightly job means the agent can escalate silently — exactly the risk to avoid. The safe configuration is a restrictive permission mode plus a sandbox, with any escalation surfaced rather than auto-approved.
2. Internet access is over-open. A dependency upgrade may need network access to fetch packages, but full internet access is more than the task requires and carries data-handling risk in a fintech context. Grant the minimum the task needs, deliberately.
3. Experimental context management is unavailable here. At launch it is Plus/Pro sign-in only; a ChatGPT Enterprise workspace cannot use it. The proposal fails on availability, so “keep notes across the long task” must be solved another way (scoping, subagents, or accepting the limit) — not by this feature.
4. Auto-review is not a substitute for human review. It produces a useful summary to attach as evidence, but auto-merging on auto-review removes the human gate. For a fintech dependency change, a human review before merge is exactly the control you keep.
5. Reassemble the safe design. Restrictive permission mode + sandbox, minimal deliberate internet access, drop the experimental feature on this workspace, and require a human review of the auto-review summary and diff before merge.

Exam-correct decision: restrictive permission mode with a sandbox, least-privilege cloud internet access granted only for the fetch, no reliance on experimental context management on an Enterprise workspace, and auto-review used as evidence feeding a required human review gate — not auto-merge. Not broad auto-approve, not full internet access, not experimental context management on Enterprise, not auto-merge on auto-review.

Assessment traps

Practice questions

Each item states how many responses to select. Attempt before revealing.

Key takeaways

• One shared config.toml sets defaults (model, features, permissions) for the desktop app, CLI and IDE extension; AGENTS.md holds per-repository guidance.
• Extend deliberately: skills for reusable abilities, plugins for bundled behaviour, MCP for external systems/data, hooks for lifecycle logic, record & replay for reproducibility.
• Match permission modes and profiles to the risk; unattended runs need a restrictive mode plus a sandbox.
• Sandboxing contains the blast radius; on Windows, use the Windows sandbox or WSL.
• Auto-review produces reviewer evidence but does not replace a human review gate.
• Default cloud internet access to restricted; open it deliberately for the specific need.
• Experimental context management is opt-in via features.context_management.experimental_mode and, at launch, is Plus/Pro sign-in only — not Business/Enterprise/API-key.