Keyboard shortcuts

jk
move through the list
↵
open the selected item
a
ask a question
nucw
tabs: new, unanswered, active, top
⌘↵
post the answer you are writing
/or⌘K
search
t
switch theme
?
this list
AskVibe
AskSign in
…
Sign in
Question

Long Codex session gets worse and worse, it forgets what we decided an hour ago

Solved · 331 viewsasked by yuki_builds
codexcontext-windowpythonfastapi

Building a FastAPI backend with Codex. The first hour is great. After that it starts re-adding things I asked it to remove, uses the old table names again, and once it rewrote an endpoint we had already finished.

Is this a bug or am I using it wrong?

What I’ve tried

Reminded it of the decisions in the chat. Helps for a few messages, then it drifts again.

Comment

2 answers

Marked as helpful by the asker
marco_py

Not a bug. Every model has a limited context window, and in a long session the early decisions get squeezed out or summarised away.

What works for me:

  • Write decisions down in the repo, not in the chat. A short DECISIONS.md or a section in AGENTS.md: table names, what is finished, what not to touch.
  • One task per session. When a task is done, start fresh with /new. The new session reads AGENTS.md again, so it knows the decisions without the noise.
  • If you must keep going, /compact summarises the conversation so far. Better than nothing, but a file beats a summary.
Comment
Started keeping a DECISIONS.md and a new session per endpoint. Night and day. yuki_builds
sergio_ruiz

A signal worth watching: the moment it re-adds something you removed, stop. Don't correct it in the same session. Every correction is more context about the thing you don't want, and the old version is still in there too.

My routine on long builds: at the end of a task I ask it to write a five-line handoff into DECISIONS.md (what changed, current table names, what is done), I read it, fix anything wrong, commit, /new. Takes a minute, and the next session starts sharper than the last one ended.

Comment
Having it write the handoff itself is clever. It's also a quick check on whether it understood what we did. yuki_builds
Exactly. If the handoff is wrong you've caught the drift before it costs you a rewrite. sergio_ruiz

Related

FastAPI BackgroundTasks sometimes just don't send the email3 ans.
FastAPI gets completely stuck when one user is waiting for the OpenAI responsesolved
FastAPI backend on Railway times out on the first request each morningsolved
SQLAlchemy QueuePool limit of size 5 overflow 10 reached after a few hourssolved
pytest: ModuleNotFoundError: No module named 'app' but the app runs finesolved

Your answer

Sign in to write an answer