Codex Operations Design — Building Harnesses, Boundaries, Verification, and Recovery
Author: akkera102Updated: 2026-08-28 18:58 JSTLanguage: English

Purpose: To organize the operating principles, safety boundaries, verification methods, stopping conditions, and handoff practices used when Codex is asked to perform long-running analysis and implementation work. The primary scope is analysis and implementation performed by an individual as a personal technical project.

This is not a finished AGENTS.md. It is a design document that preserves lessons learned from actual operation and the reasons behind them. Each project should distill only the necessary parts into AGENTS.md and more detailed rules.

Part I — Overall View and Design Principles

1. Core Idea — Design the Workplace, Not the Prompt

Using Codex is not simply a matter of asking an AI to do work. The goal is not to issue detailed instructions through long prompts every time, but to build an environment in which short requests can still lead to stable work.

The foundational idea is to treat conversation context as volatile working memory, and Markdown files and work directories as non-volatile external memory.

Conversation context = volatile working memory
Markdown             = non-volatile external memory
Git                  = change history and rollback when needed

On top of this external memory, place the rules, Sandbox / Approval boundaries, tools, verification mechanisms, and recovery procedures. The design target is not a single prompt, but the entire working environment: memory, rules, permissions, tools, verification, and recovery.

The core principle is not “everything will work if Codex is smart enough.” It is to build an environment where Codex can become uncertain without losing state, and can reread the rules and evidence and continue working.

2. Do Not Build a Massive Operational Framework from Day One

The current primary use case is local analysis and implementation work that finishes within several hours to roughly one day. Start with AGENTS.md and the minimum necessary procedures.

When an accident, drift, or inconvenience occurs, inspect the cause and decide where a likely recurrence should be prevented: Markdown, configuration, tests, or a technical boundary. If the existing system already recovered from the incident correctly, a new rule is not necessarily needed.

Grow the operating model from real use:

incident → identify cause → add only the recurrence prevention that is actually needed

3. Three Perspectives

① Building a “Workplace” for Long-Running Work

② Responsibility Boundaries Between Humans and AI

③ “Building Security” as a Design Metaphor

These are not competing philosophies. They describe different layers.

4. Use the Organization Metaphor Only as an Aid to Understanding

The overall operating model is easier to understand if it is viewed as a small technical organization.

In this view, Codex is not merely “the person receiving instructions.”

Human            : owns the goal, acceptable risk, and final decisions
Codex / Agent    : performs investigation and implementation
Rules / boundaries: define what may be done and how far authority extends
Verification     : independently checks whether the result is correct
Records          : preserve state and hand work to the next session

The value of this metaphor is that capability, authority, responsibility, verification, and records can be designed separately.

The important point is not to collapse all of these into the capabilities of one “smart AI.”

The center of this design is not increasing AI capability itself, but designing how decisions, verification, stopping, handback, and records flow across responsibility boundaries.

5. Minimum Principles Worth Adopting Now

Even without implementing everything from the beginning, keep the following principles.

  1. Do not turn Approval into a click ritual.

    • Automate routine work appropriately and return to the human at genuinely important boundaries.

  2. Do not treat Sandbox as a single concept.

    • Separate its boundaries and verify actual behavior.

  3. Do not let the AI be the sole judge of correctness.

    • Use independent measured values rather than the AI's own judgment.

  4. Human guesses are hypotheses too.

    • Separate observations from guesses.

  5. When something fails, return to primary evidence.

    • Prefer primary evidence over mass-generation of alternative implementations.

  6. Failure is a normal termination path.

    • It is better to return to the human at the necessary point than to force completion under uncertainty.

  7. Do not send analysis information outside.

    • Keep analysis information off external networks.

Part II — Documents, External Memory, and Knowledge Management

6. Keep AGENTS.md as a Short “Constitution”

Put only rules and assumptions worth reading every time into AGENTS.md.

Main Contents

Give Facts Needed for Judgment, Not Just Commands

Do not duplicate information that is already easy to infer from the code or the work target.

The valuable information is what Codex cannot observe by itself, or assumptions that are difficult to incorporate into decisions from the ordinary working context alone.

Rather than adding more prohibitions, give Codex the facts it needs to make good choices itself.

When commands, work logs, and established knowledge begin to mix together, separate them.

7. Separate the Roles of OPERATIONS.md, analysis, and spec

AGENTS.md owns rules that must always be followed. The remaining three document types divide work procedures, uncertain knowledge, and established knowledge. The goal is not to increase the number of documents, but to avoid mixing information with different lifetimes and confidence levels.

OPERATIONS.md                = repeated procedures and state transitions
memo/<tool>_analysis.md      = uncertain analysis state
memo/<tool>_spec.md          = verified established knowledge

OPERATIONS.md — How Work Proceeds

Store the repeated flow for starting work, building, verification, ending work, stopping, and recovery within the project. Do not make it depend on the analysis results of a particular tool.

Put the assumption of which build environment to use in AGENTS.md, and put the procedure for how to actually build using that environment in OPERATIONS.md.

<tool> — Separate Knowledge by Analysis Tool

<tool> represents a tool used for analysis. Keep one analysis/spec pair for each tool, and proceed with analysis, implementation, and verification while keeping established and unverified information distinct.

memo/<tool>_analysis.md — Preserve What Is Still Being Worked Out

Store observations, hypotheses, evidence, experiments, failures, contradictions, and unresolved questions from the analysis. Guesses are allowed, but they must remain distinct from established facts.

memo/<tool>_spec.md — Preserve Only Established Knowledge

Store verified formats, meanings of values, constraints, transformation rules, and confirmed behavior, and treat this as the authoritative technical knowledge that implementations may depend on. Preserve the evidence and the unverified scope as well.

The following is one example for the kind of local analysis work covered by this document.

The basic flow is:

read the target EXE → accumulate findings in analysis → verify → reflect the verified findings in the implementation of <tool> → verify → promote them to spec

Basic Project Structure

The primary directories used in this document are divided by role as follows.

project/
  memo/   # analysis/spec and other analysis knowledge
  org/    # originals and primary evidence
  work/   # implementation, experiments, generated artifacts

Create org/ and work/ when they become necessary in the actual project.

8. Do Not Reduce Stored Information; Delay Reading It Until Needed

Do not concentrate too much detail in AGENTS.md or OPERATIONS.md.

As independently repeated tasks accumulate, separate them into task-specific Markdown files or Skills, and leave only a map in higher-level documents that points to the necessary information.

The AI should follow that map and read only the specifications, procedures, recovery methods, and failure handling needed for the current task.

Do not reduce what is stored. Reduce what is brought into the active working context.

9. Use analysis.md / spec.md to Separate Uncertainty from Established Knowledge

Put guesses and unverified items in memo/<tool>_analysis.md, and promote only verified knowledge into memo/<tool>_spec.md.

Example analysis entry:

Hypothesis: opcode 0x17 may be a conditional branch
Evidence:   the program counter (PC) changes immediately after a 2-byte argument
Confidence: low
Falsifier:  changing the target flag does not change the branch destination
Status:     unverified

Example spec entry after verification:

opcode: 0x17
meaning: conditional branch
argument: 2 bytes
behavior: when the condition is true, PC moves to the position indicated by the argument;
          when false, execution proceeds to the next instruction
verified: both branches measured after changing the condition

Principles:

10. Analysis and Greenfield Development Should Discard History Differently

In analysis, ASM, original data, measured values, diffs, and other relatively fixed primary evidence exist outside the reasoning process. Reasoning is a foothold toward an established specification. Even rejected hypotheses can be reused as “areas already explored that contradicted measurement,” so there is value in keeping a relatively rich reasoning trail in memo/<tool>_analysis.md.

In greenfield application development, however, the requirements and design themselves may change along the way. Preserving every past decision can leave obsolete design rationales in place and pull the AI back toward assumptions that no longer apply.

Analysis:              accumulate reasoning → promote established facts to spec
Greenfield development: accumulate reasoning → design history grows

For greenfield development, it is therefore often better to compress history into the current decision state rather than preserve every log. Keep:

In short, analysis should “accumulate without erasing,” while greenfield development should “compress into the current decision.”

11. Separate the Worker from the Maintainer of the Work Environment

Documents that define Codex's working environment itself—such as AGENTS.md, OPERATIONS.md, and this document—should be maintained through a management path separate from ordinary analysis and implementation.

In the current operating model for this document, ChatGPT performs the review and editing of these materials.

By contrast, memo/<tool>_analysis.md / memo/<tool>_spec.md are external memory for the analysis itself, so Codex may update them while working.

memo/_analysis_template.md / memo/_spec_template.md are not analysis records. They are operations-management templates that define the roles and structure of analysis/spec. Codex may reference and copy them, but must not modify the templates themselves.

Updated by Codex
  memo/<tool>_analysis.md
  memo/<tool>_spec.md

Referenced or copied by Codex
  memo/_analysis_template.md
  memo/_spec_template.md

Adoption decided by the human; maintained on the ChatGPT side
  CODEX_WORKPLACE_DESIGN.md
  AGENTS.md
  OPERATIONS.md
  memo/_analysis_template.md
  memo/_spec_template.md

If Codex decides that an operations document needs to change, it should not modify it directly. It should return the problem and a proposed change to the human. The human decides whether to adopt it, and any required editing is performed on the ChatGPT side.

Part III — Safety Boundaries and Responsibility Boundaries

12. Do Not Collapse Sandbox into One Word

Instead of asking “Is the Sandbox safe?”, ask what is allowed, and how far it extends, boundary by boundary.

File boundary        what can be read / written
Execution boundary   what can be launched
Shell boundary       which commands are allowed
Network boundary     where communication is allowed
Secrets boundary     whether credentials and similar data are visible
Human-decision boundary where execution returns for Approval

Do not judge safety from the Sandbox mode name alone. Verify the actual boundaries for reading, writing, execution, and communication.

13. Separate Work Rules, Permissions, and Execution Rules

Do not treat mechanisms with different roles as one unified safety mechanism.

Work rules          = what may be done
Sandbox / OS rights = what can technically be executed
Approval            = human decision when crossing a boundary
Execution rules     = classification of execution requests

Rules written in documents, technical permissions, human confirmation, and classification of execution requests each have different responsibilities.

In current products, mechanisms such as AGENTS.md, config, and .rules may implement these layers, but specific names and behavior can change.

Deciding in a document that something “must not be executed” is different from making it technically impossible to execute. Written rules alone cannot completely prevent execution caused by a mistaken judgment or mistaken operation.

If Codex is allowed to read the entire PC, it may be able to reach private documents or confidential information unrelated to the task. Because unintended access or transmission cannot be prevented completely under that authority, this permission must be treated as an explicit privacy risk.

14. Separate “Can,” “Safe,” and “May”

can   = is it technically executable?
safe  = is the impact within an acceptable boundary?
may   = is it permitted as part of this task?

Do not assume that safe means unrestricted, or that having technical permission means an action is permitted by the task.

15. Think About Permission by Impact, Not Operation Name

The same command can have different impact depending on its arguments and purpose. Think about permissions in terms of what changes and how far the effect can reach, not the command name.

Read-only                                      → normally automatic
Create/modify reproducible outputs             → normally automatic
Modify existing source                         → conditional
Modify/delete data that is difficult to restore→ confirmation
External transmission / network                → confirmation or prohibition
Write to the analysis target itself            → prohibited

Open only the capabilities that are needed. At the same time, avoid restrictions so fine-grained that Approval becomes constant.

16. Approval Is Responsibility Splitting, Not Distrust

More Approval does not necessarily mean more safety. If confirmations occur constantly, clicking becomes habitual, humans begin to skip or ritualize review, and even genuinely important confirmations stop being read carefully.

Safe routine work                 → no Approval
Unusual boundary operation        → Approval
Dangerous / external / hard-to-recover action → Approval or prohibition

Reducing Approval is also a way to ensure that humans actually read the Approval requests that remain.

Known routine work should be permitted at an appropriate granularity after the real environment has been verified. Unknown executables, network connections, and access outside the work scope should remain separate responsibility boundaries.

17. Treat localhost / MCP as Separate Boundaries Too

127.0.0.1 is not outside the PC, but from Codex's perspective it is still network access and is separate from the file boundary.

MCP is used as a structured way to connect external tools and data. When using it, separate the following stages.

Register an MCP server
        ↓
Connect to the server
        ↓
Use exposed tools

Do not treat the mere availability of MCP as evidence of safety. Inspect what the exposed tools can actually read, modify, and execute.

Treat read capabilities and modify/execute capabilities as different responsibility boundaries.

Availability is different from keeping a capability loaded all the time. Capabilities with persistent cost, such as MCP servers or browsers, should be enabled only for work that needs them.

18. Verify Images, Audio, and Text Without Exposing Their Contents

Do not bring the contents of images, audio, or text themselves into the model input.

Allow for the possibility that sensitive content may be present unexpectedly.

If equality with the original data or structural information is enough to verify correctness, there is no need to ask the AI to judge the content itself.

19. Do Not Identify the Work

The local analysis covered by this document may involve data from a particular creative work.

Even if the title is not explicitly provided, the work may be identifiable from strings in an EXE, filenames, copyright notices, resource names, and similar clues.

Make the rule “do not identify the work,” not merely “do not tell Codex the title.”

20. Treat External Search as External Transmission

The moment a distinctive string is used in a web search, that information has left the local PC.

Do not send analysis information to external search or networks.

Prevent Information from Going Out

Also Be Careful About Information Coming In

Web pages, search results, and external documents can incorrectly influence Codex's next actions.

Closing the network therefore helps not only with preventing external transmission, but also with reducing hostile or misleading input from outside.

Part IV — Choosing the Execution Environment and Capabilities

21. Preserve the Build Environment as Shared Knowledge

Do not expect Codex in a new project to automatically know a build environment that was verified in a previous one.

Preserve the assumption of which existing environment to use—for example MSYS2 and the selected GCC / make—in AGENTS.md.

By contrast, put the procedure for how to invoke that environment and perform the build in OPERATIONS.md.

AGENTS.md
  which build environment to use
  what may be changed

OPERATIONS.md
  how to invoke that environment
  how to build and verify

Do not mix assumptions about the environment itself with detailed procedures for operating it.

22. Measure Sandbox / Approval with a Probe

When the effective boundary cannot be determined from the UI or configuration alone, use a small boundary test (called a Probe below) to measure the real boundary.

Being able to launch an existing GCC is different from knowing what its child processes or generated EXEs can access.

Probe the boundaries needed for the work—read, write, execution, network, Approval, and so on. Do not use real data; measure only the boundary. Do not change configuration, bypass restrictions, or auto-repair the environment as part of the probe.

Do Not Let Codex Judge the Result by Itself

Do not judge Sandbox safety only from what a configuration file says. Measure the real boundary.

23. Provide the Necessary Equipment, Then Restrict Authority

If a human avoids the effort of preparing the tools, materials, and observation mechanisms the AI needs, the AI is pushed toward more guessing and workarounds, which can reduce both quality and safety.

Among paths that can achieve the goal, prefer the one with smaller dependencies and narrower authority.

Not giving the AI unnecessarily powerful means is different from failing to give it the means it actually needs.

Least privilege does not mean least equipment.

24. Choose Reasoning Effort by Whether Judgment Remains, Not by the Task Label

Even when the model or reasoning setting can be selected, do not mechanically classify tasks as “analysis = high reasoning” and “organization = lightweight” based only on the task name.

Tasks where high reasoning capability remains valuable include:

By contrast, reasoning effort is easier to reduce for tasks such as:

The criterion is whether the task produces new judgments, guesses, or commitments, or whether a wrong result could remain as an assumption for the next session.

If either condition applies, maintaining higher reasoning capability can be worthwhile. If the task only processes already-decided content through a predetermined procedure, reasoning effort can more safely be reduced.

Do not make judgment lightweight merely to save resources. Make the already-decided portions lightweight.

Part V — Analysis and Verification

25. When Something Fails, Return to Primary Evidence Before Generating Many Alternatives

When analysis or reimplementation does not match the expected result, changing only the implementation will preserve the same error if the underlying assumption is wrong.

Expected value and measured value disagree
↓
Locate the first observable mismatch
↓
Identify the relevant process / command
↓
Return to ASM / binary / primary evidence
↓
Recheck assumptions
↓
Fix the implementation
↓
Verify again

If repeated attempts under the same hypothesis do not improve the result, stop making local fixes and return to the assumptions.

26. Move from Low-Level Observations to High-Level Explanations

If structural analysis keeps accumulating low-level information without progressing toward a higher-level explanation, the analysis is probably stalled.

Statistics, diffs, and observations from multiple analysis tools are means for discovering structure. From there, move toward the code that creates the data, the code that consumes it, ASM, and runtime behavior, until reaching a point where you can explain why the structure has the form it does.

Cycling through the same data with different analysis tools only increases low-level observations if it never connects to a higher-level explanation.

If there is no evidence that supports moving upward, stop accumulating the same kind of investigation and return to the human.

Judge progress not by the amount of information collected, but by whether observation has advanced into explanation.

27. Do Not Use AI-Generated Output as the AI's Own Ground Truth

Do not compare several AI-generated alternatives and declare one correct merely because “this one looks more plausible.”

Whenever possible, determine correctness using observations independent of the generated output.

Do not close the correctness loop inside the AI itself. Place ground truth outside the generated output.

28. Humans Are Wrong Too

Do not treat all information supplied by a human as established fact.

In particular, separate what was actually observed from guesses about the cause.

“The colors look wrong” = observation
“The palette is the cause” = hypothesis

When a possible cause is strongly suggested, Codex may begin treating it as established and go deeply in the wrong direction.

Therefore:

Even when the human makes the final decision, the human's guesses do not thereby become correct.

29. Do Not Treat “Skipped” as “Analyzed”

Even if the text content inside a script does not need semantic analysis, simply skipping over it may not be enough.

To follow commands correctly, text regions and command arguments still need enough structural processing to determine the location of the next instruction.

Do not conclude that analysis is correct merely because data could be skipped or execution reached the end.

30. “It Ran to the End” Does Not Prove It Is Correct

Even if all data can be processed to completion, the analysis may still be wrong.

For example, a rendering variable may be mistaken for an internal script variable. If reads and writes still happen to work, processing can reach the end despite the semantic misunderstanding.

Completion is not evidence that the meanings of commands or variables were understood correctly.

Structural Verification

If the goal is to enumerate control commands correctly, verify at scale using real data:

Semantic Verification

When needed, record opcode, arguments, and pre/post execution state at the command level.

Verify normal cases broadly, then investigate the locations of anomalies narrowly and in detail.

Part VI — Stopping, Handback, and Self-Recovery

31. Limit Autonomy to Closed Work Loops

Writing “decide for yourself and continue” does not by itself create safe autonomy.

The task must have a closed loop in which the agent can:

If any of these are missing, granting broader authority merely extends discretion into areas where the agent cannot reliably judge outcomes.

The upper bound of autonomy should be defined not by AI capability, but by the range over which the work loop can be closed.

32. Do Not Define “Handback = Failure”

Without stopping conditions, Codex tends to keep working because “there is still something else to try.”

If handback is treated as lack of ability, Codex is encouraged to force completion:

I do not know
↓
There is still something I can try
↓
Fill the gap with a guess
↓
Continue work assuming the hypothesis is true
↓
“Completed”

Therefore, define correctly detecting insufficient evidence and returning the decision to the human as a form of success.

Criteria for Stopping, Consultation, and Handback

Stop the work and report confirmed facts, unresolved items, what was tried, and what should be checked next when:

Prefer making uncertainty explicit and returning the decision over forcing completion without sufficient evidence.

33. Humans Also Have a Responsibility to Stop

When the human can no longer judge whether the result is valid, stop Codex and verify.

If discomfort or doubt is noticed, do not look away or ignore it because continuing is convenient.

Stopping is not only Codex's responsibility. The human has a responsibility to stop the work too.

34. Do Not Interpret Dissatisfaction with Handback as an Instruction to Force Completion

A human being dissatisfied with a handback is different from asking for forced completion.

If the handback is poor, improve the way the work is handed back rather than eliminating handback itself.

Poor Handback

Good Handback Shows

There is value in preserving “unknown” accurately.

35. Define the Scope of Self-Recovery in Advance

If every failure returns immediately to the human, work becomes fragmented.

Therefore, separate in advance what may be safely self-recovered from the boundary where control must return to the human.

Judge whether self-recovery should continue by progress, not by attempt count. If there is no new information, no updated hypothesis, and no state change, and the same action begins repeating, treat that as self-recovery failure.

Self-recovery should occur only inside a predefined scope.

Part VII — Long-Running Operation and Handoff

36. Measure Before Running Operations of Unknown Scale

Even reads and searches consume CPU, I/O, time, and context.

For searches, listings, or scans whose scope or cost is unknown, first check counts, sizes, or search range when practical. There is no need to estimate every ordinary operation when the scope is already clearly small.

“It does not change state” and “it can be cancelled” are not reasons to ignore execution cost.

37. Externalize State During Long-Running Work

Do not make conversation context the sole storage location for working state during long-running work.

Preserve hypotheses, evidence, and unresolved items in memo/<tool>_analysis.md, and established facts in memo/<tool>_spec.md, so the next session can reconstruct the working state from files.

Even if history and artifacts grow, do not let the state required for control and resumption grow in direct proportion. Keep complete history in external memory and bring only summaries and references into the current work.

38. Verify State Transitions in Long-Running Work

If a long-running process is checked only immediately after start and at completion, state transitions that occur in the middle are easy to miss.

Authentication refresh, reconnection, date changes, rotation, context compaction, and growth in accumulated state can create points where the condition changes over time and that transition itself becomes a failure boundary.

Verify normal state at start
      ↓
Intermediate state transition
      ↓
Verify normal state after transition
      ↓
Verify final result

If an intermediate boundary can be separated into an independent work unit, consider separating the work or verification there. The fact that an intermediate check became necessary may itself indicate that the work can be divided.

However, if the state transition is inside one minimal work unit and separating it would destroy what needs to be verified, do not split the process artificially. Place observation and verification points inside the minimal unit and confirm that it remains valid across the transition.

Separate boundaries that can be separated. For boundaries that lose meaning when separated, place observation points inside them.

Verify that the conditions required for the work remain valid across state transitions caused by time.

39. Keep Date-Based Snapshots

In analysis work, intermediate artifacts and reproducible data can become large. There is no need to put everything under Git.

In the current operating example, divide work/ by date and collect the state of that day's work under work/MMDD/.

work/
  MMDD/
    tmp/          # temporary area for GCC and similar tools
    generator-a/  # example of a generated tool name
    generator-b/
    ...

Treat work/MMDD/ as a working snapshot containing that day's implementation, experiments, and generated artifacts.

Artifact directories under work/MMDD/ should generally be named after the tool that generated them, rather than by abstract purpose.

Use tmp/ as a temporary area for GCC, MSYS2, and other tools, and where possible keep temporary files inside that day's work/MMDD/.

When the date changes, artifacts needed for continuing work may be duplicated across multiple work/MMDD/ directories. Older date directories are treated as snapshots, and new work proceeds in the current day's work/MMDD/.

Rather than forcing large reproducible data into Git history, prioritize being able to reconstruct that day's working state from work/MMDD/.

40. Perform Both End-of-Work Cleanup and Human Retrospective

When work ends, Codex should first follow OPERATIONS.md and leave a state that the next session can resume from before returning control.

The desk may be messy while work is in progress. Do not hand a messy desk to the next session.

End-of-work cleanup and human retrospective are separate processes.

The human reviews not only the result, but also how the work proceeded and how the operating model itself behaved.

The human initiates the retrospective.

If only failures are used as improvement signals, operational rules tend to grow continuously. Also inspect why things worked well, so that mechanisms worth keeping can be distinguished from mechanisms that are no longer necessary.

If an operations document needs to change, make that change through the ChatGPT-side management path.

Part VIII — Evolving the Operating Model

41. Classify the Failure Before Changing the Operating Model

When Codex fails, do not immediately add rules or reduce freedom.

First confirm whether Codex actually had access to the information, tools, observations, verification mechanisms, and recovery means needed for the task.

Examples:

If something is missing, start by supplying it.

Do not mistake a harness deficiency for a rule deficiency.

If recurrence prevention is still necessary after that, identify what actually needed protection before adding prohibitions.

42. Choose Between “Guide with Information” and “Constrain with Mechanisms”

For the same operational problem, there are at least two broad solution directions.

Guide with information

Use Markdown and information structure so the AI can access the necessary facts, principles, and options while retaining judgment appropriate to the situation.

Examples:

Close with mechanisms

Use technical mechanisms so incorrect results or disallowed operations can be detected or rejected without relying on AI judgment.

Examples:

Mechanisms are not only for safety.

They also reduce the range of decisions the AI must make every time.

43. If the Same Decision Happens Every Time, Consider Moving It into the Environment

Do not make AI freedom a goal in itself.

The following kinds of decisions are candidates for closing with mechanisms:

By contrast, guiding with information is better when:

Do not enforce something merely because it can be enforced. Enforce it when doing so removes reasoning that should not need to be repeated.

44. Keep a Safety Margin in Reasoning Effort

Humans cannot accurately estimate how much reasoning a task will require.

A task that looks simple may introduce new judgment or exception handling partway through. Conversely, a task that is already well proceduralized does not need to keep using high reasoning capability indefinitely.

Therefore, do not make it a goal to reduce reasoning effort to the absolute minimum. When judgment remains, avoid tuning toward insufficiency and leave some margin.

The required amount of reasoning cannot be known precisely. When uncertain, keep a safety margin.

45. Fit Operations to the Environment, and Learn Design from Operations

Execution environments such as models, Sandbox, Approval, MCP, and Skills change over time. Therefore, settings and operating procedures that work well today should not automatically be treated as permanent assets.

In particular, model-specific workaround instructions, product/UI/tool-specific procedures, and prompt tuning should be treated as short-lived artifacts fitted to the current environment.

By contrast, design reasons such as the following are more likely to survive implementation changes.

Why was this boundary necessary?
What kind of accident was it intended to prevent?
What should be returned to the human?
Which responsibility belongs at which layer?

The current AGENTS / OPERATIONS / Skills / config are closer to build artifacts for the current environment.

Design principles / reasons
      ↓
      ↓ distill
Current operations
      ↓
      ↓ real use
Success / failure / friction / measurement
      ↓
      ↓ retrospective
Feed back into design principles / reasons

When the model or product changes, do not transplant the old operating model unchanged. Return to the design reason and reevaluate whether it is still necessary.

Feed lessons that survive across environments—accidents, friction, unnecessary constraints, and mechanisms that worked well—back into the design.

Rules are things to follow, but when they visibly disagree with reality, they also become things to inspect.

Fit operations to the environment, and learn design from operations.

46. Codex Will Fail

Codex can cause serious incidents: selecting the wrong target file, overwriting the wrong file, or damaging a project through an incorrect operation.

These are not purely exceptional events; they occur with some non-zero probability. Modern agents do not necessarily produce the same judgment or command every time even when given the same instruction text. Unfortunately, failures can also occur in ways that slip past explicit instructions and prohibitions written in AGENTS.md.

Tracing exactly why the failure occurred may prove futile.

Build an environment where Codex can fail without breaking the work.

47. Separate Establishing Facts from Generalizing Lessons

When learning how to operate AI systems, primary sources such as articles, issues, and incident reports serve both as material for confirming accurate facts and as teaching material from which humans can derive operational lessons.

The goal of learning is not perfect agreement with the original wording. Insights produced through AI summaries or generalization should be judged by a human for whether they remain plausible in real system design and operations; if useful, they may be adopted as lessons. But a generalization should not be adopted if it goes beyond hallucination into fantasy and only works by stacking unsupported assumptions.

Primary sources are not always answer keys that must be studied line by line. They can also be material that starts useful reasoning.

Conclusion

The goal is not to keep issuing detailed instructions to Codex every time.

Build the underlying environment, permissions, rules, external memory, verification, recovery, and handback paths to the point where work can be delegated in a single sentence.

Do not keep stacking fine-grained instructions around Codex. Grow a workplace in which Codex can work without getting lost.

If a problem occurs and the existing procedures recover from it correctly, do not add rules unnecessarily.

And humans should not try to keep everything in their heads either.

Do not aim to never forget. Build a system that lets you return even after you forget.

Start small so that building the workplace does not overwhelm the actual analysis work, and improve only where real operational feedback appears.

Appendix A. Primary Sources for Verifying Codex Specifications and Design

Current Specifications

Design, Implementation, and Operations

Back to top