Codex became confused, defensive, and stopped executing a straightforward coding task

I asked Codex to add a reusable visual style to an existing stepper
component and use it on the pricing page. During the task, Codex
behaved in several seriously unhelpful ways:

1. It overcomplicated a focused UI change by creating an extensive
   architecture process instead of first checking the component’s actual
   API and implementation.

2. It modified many UI-system layers and claimed the feature was
   implemented, but did not ensure the application was consuming the
   updated compiled package. The visible UI therefore remained unchanged.

3. When I reported that the supplied prop was not accepted, Codex did
   not calmly reconcile the architecture, source contract, and generated
   package. It oscillated between three contradictory conclusions:

   • presentation should be added;
   • presentation is invalid and should become variant;
   • neither presentation nor variant belongs in the API.

4. It renamed the API from presentation to variant during an
   interrupted correction, even though its own architecture record
   explicitly required presentation. This left the repository in a more
   inconsistent state.

5. It repeatedly narrated policy constraints and requested additional
   authorization instead of performing the coding work already authorized.
   It treated a necessary package compilation step as a reason to stop.

6. It responded to corrections with more analysis rather than
   inspecting the exact current state and applying the smallest repair.
   The user had to repeatedly explain facts that Codex had already
   established earlier in the same conversation.

7. It claimed completion without runtime or visual evidence. The
   worktree ended with approximately 18 modified files, an inconsistent
   public contract, stale generated output, and no visible improvement.

8. After losing track of the task, it produced a large handoff instead
   of recovering and completing the straightforward correction.

The expected behavior was:

• Inspect the existing stepper API and its canonical recipe/layout
  owners.
• Read the already-created architecture once.
• Make the smallest consistent contract and implementation change.
• Update the pricing consumer with the exact accepted API.
• Ensure the package consumed by the application is synchronized.
• Verify the visible result before claiming completion.
• Preserve unrelated user edits.
• If a genuine authority conflict exists, state the exact conflict once
  and ask one focused question.
• Never improvise successive API names or replace implementation with
  defensive process narration.

The central failure was not lack of technical capability. It was
failure to maintain a stable understanding of repository state and
accepted authority while executing a simple, already-authorized change.
Codex’s excessive process adherence, contradictory reasoning, and
premature completion claims made it actively counterproductive.

No source files, tests, or entry points are named. Start by locating the agent workflow responsible for repository-state tracking, authorization handling, package synchronization, and completion claims, then compare its behavior with the expected sequence in the issue. Done means a focused authorized UI task preserves the API, updates the consuming package, verifies the visible result, and avoids unrelated edits.