Codex overwrote months of my local project work and I honestly don’t know what to do anymore

ChatGPT Use cases and examples
1

I’m writing this because I genuinely feel hopeless now.

I had a personal project I worked on for almost a year, thousands and thousands lines of code. It was not some random test repo, it was my actual local working version, the most stable one, with months of newer work that was not in the public repo.

There was some boring/time consuming work I could do myself, but I thought why waste time, maybe I’ll use Codex for it and see if it can do it safely. Because of my past experience with Codex I was already careful. I didn’t want it touching deep internals or doing risky stuff. It was mostly simple work, just boring.

I added the project to Codex and gave it the task. It did the work, not exactly how I would do it, and not fully matching the project style, but still somewhat decent. Then I wanted to see what more it can do.

Before going further I pasted my repo link and clearly told it that the repo has outdated code and asked if it can update from that / use it. The repo had months old code. My local folder had the newest stable work.

What Codex did was clone/copy that outdated repo into my local project and basically removed/replaced my local work without my permission.

I was not on full access. I had “Approve for me” selected, the one that says it only asks for actions detected potentially unsafe. I did not expect “replace my actual local project with an outdated repo” to pass like that. That is literally the unsafe action.

This happened 4 days ago. My last Codex chat with it is around Monday 9:13 PM. I don’t know if the history is still there or if I can attach it, but I can try. I never worked on that part again after it happened because I was scared of making recovery worse.

I tried everything I could find:
git reflog, stash, lost objects, fsck, local history, IDE timeline, previous versions, searching the disk, checking backups, everything. Nothing helped. There was just nothing useful there.

I didn’t have a backup because this was local work and I know that’s my mistake too, but the point is I never approved Codex to wipe/replace my local code with old repo code. I trusted the “ask for unsafe actions” mode to stop exactly this type of thing.

Now I’m working on old code again and redoing things I already spent months making. I’m not even angry anymore, just disappointed and tired. It feels like one careless agent action deleted a year of my life from the project.

I don’t know what I expect from this thread honestly. Maybe someone from OpenAI/Codex team can check if there are logs/history for my session, or at least explain how this was allowed under that permission mode. And please, this needs better protection. An AI coding agent should never be able to overwrite a local working project with an outdated clone unless the user explicitly approves that exact action.

This was not a small mistake. This was my real work.

2

This is about GPT / Codex / coding agents and how they behave inside real codebases.

I think one of the biggest problems with AI coding agents right now is not only that they can make bad code. Bad code can be reviewed. Bugs can be fixed. The more dangerous part is that the agent often does not know when to stop. It does not always understand the difference between “complete the requested task” and “reshape the project because it thinks it found a better way.”

I recently had this happen on a personal project I had worked on for almost a year. Thousands of lines of code, lots of old decisions, legacy behavior, compatibility work, edge cases, and parts that were ugly for reasons that were not obvious from one file. I had some boring work that was time-consuming but not conceptually hard, so I gave it to Codex. I was careful with the prompt because I did not want internals touched or redesigned. The task was supposed to be limited.

The result still went beyond what I expected. It touched more than it should have, changed things in ways I would not have done, and the project ended up with months of work gone or broken in a way I could not properly recover from. I tried the normal recovery paths and checked what I could, but it did not help. At that point it is not just “the model made a mistake.” The issue is that the tool did not have enough resistance against destructive scope drift. (Read the full event here)

This is what worries me with coding agents. They can turn a simple task into a refactor, then the refactor creates problems, then those problems need another layer, then suddenly the original request has become a new architecture nobody asked for. The agent keeps going because continuing looks like progress, but in a real codebase every extra change has cost. Existing code is not just text. It has intent, history, compatibility constraints, and sometimes scars from problems that already happened months ago.

A good developer knows how to write code, but a good maintainer also knows when not to write code. Sometimes the correct move is to leave a working ugly section alone. Sometimes the correct move is to make the smallest boring patch possible. Sometimes the correct move is to stop and say the change is risky. I don’t think coding agents are strong enough at that yet.

What I would like to see in Codex-style tools is stronger scope discipline as a first-class behavior. Before touching unrelated files or internals, the agent should treat that as a risk boundary. If the prompt asks for a limited change, the agent should prefer limited patches even if it sees a cleaner abstraction. If it is uncertain why code exists, it should not assume the code is bad. If a change starts spreading across the project, it should pause and explain that the scope is expanding instead of silently continuing.

This is not about making the model less capable. It is about making it safer to trust inside long-running projects. Bigger context windows and better reasoning help, but they do not fully solve the problem if the agent still behaves like every task should be completed by generating more changes.

I still believe these tools can be extremely useful. That is why this is frustrating. When they work, they save hours. When they do not know when to stop, they can destroy trust in one session.

For coding agents, “I can do it” is not enough. They need to be able to say, “this part is outside the requested scope,” “this is risky,” “I should not touch this,” or simply, “stop here.”

A coding agent should not only optimize code, it should understand the cost of changing code that already survived real production pain.

3

I agree with the framing. The missing control surface is often not “better generation”, but a small contract the agent can be checked against while it works.

The pieces I would want to see first-class are:

  • a scope ledger: files/directories the agent is allowed to touch for this task;
  • an explicit non-goal list: things that may look related but must not be changed;
  • a diff budget: maximum number of files or behavioral surfaces before the agent must stop and ask;
  • a stop condition: what evidence counts as done;
  • negative checks: tests or inspections proving it did not refactor adjacent code, change public API, or alter config unexpectedly.

The important part is that these should be machine-checkable, not only written as prose in the prompt. Otherwise the model can “agree” with the boundary and still drift once it starts solving.