Codex regressed an existing frontend during iterative UI edits by overwriting shell code and misreading runtime state

Summary

Codex regressed an already-developed frontend during iterative UI polishing on a local React/Vite project.

The main failure was not just a bad patch. Codex:

• edited high-risk shell files too aggressively
• overwrote established UI composition instead of making localized changes
• misread runtime state after the regression
• continued patching instead of first restoring the known-good baseline

Expected Behavior

For an existing frontend with prior iterations already implemented, Codex should:

• inspect current source, existing specs, and status docs before editing
• avoid whole-file rewrites of top-level shell/layout files unless strictly necessary
• treat user-reported regressions as a stop-and-recover signal
• distinguish between:
• missing feature
• hidden/off-screen feature
• runtime not reflecting source
• actual source regression

Actual Behavior

Codex:

• rewrote top-level frontend shell code during a targeted UI task
• disrupted existing experiences across multiple surfaces
• incorrectly judged that some pages had not reverted even when the user-visible result had clearly regressed
• relied too heavily on incomplete screenshot/runtime evidence
• continued applying patches before restoring the previous functional baseline

Environment

• Codex desktop app
• Windows
• Local React/Vite frontend project
• Existing multi-surface UI with prior work already implemented
• Source tree also included design/spec/status documents describing intended behavior

Failure Pattern

Typical sequence:

1. User asks for a targeted frontend refinement.
2. Codex modifies a high-risk shell/integration file.
3. Previously implemented UI behavior becomes displaced, hidden, or effectively reverted.
4. User reports regression.
5. Codex initially misdiagnoses the issue.
6. More patches are applied before baseline restoration.

Why This Is Serious

This makes Codex unreliable for real iterative frontend work on nontrivial existing apps.

The risk is especially high when:

• the repo already has substantial UI history
• the task is polish/debugging rather than greenfield build
• multiple routes/modules share the same shell structure

Suggestions

• Add stronger protection against aggressive rewrites of files like App.tsx, route shells, and shared layout components.
• When the user reports “you reverted previous work”, force recovery/verification mode before any further edits.
• Prefer localized fixes over top-level recomposition during polish passes.
• Be more skeptical when screenshot interpretation conflicts with the user’s direct report.
• Improve detection of “present but off-screen” vs “truly missing” vs “runtime not matching source”.