Codex Context Window Management: How to Stop AI From Forgetting Everything

Mar 25, 2026

Problem

Halfway through a coding session, Codex started asking me questions it had already asked an hour ago. It suggested a database schema that contradicted what we’d agreed on earlier. Then it proposed a component structure I’d already rejected twice.

The worst part: when I asked “why are you suggesting this?”, it had no memory of our previous discussion. The context window was full, and Codex was “spinning its wheels” before compacting.

I lost 45 minutes re-explaining decisions that should have been remembered.

What happened?

I tracked down a Reddit thread where developers discussed this exact problem. The top-voted comment (score: 5) explained what I was doing wrong:

“Keep an eye on the context window, and try to complete specific blocks of work in a single thread before Codex starts spinning its wheels and compacting. If you can manage discrete chunks of work this way, you can then commit slices to your github so you can pick up actual current-state when you start the next thread with a clean context.”

The second key insight from the same user:

“Have Codex create markdown files (.md) to capture to-do lists, security concerns, tech stack choices, milestones - anything that helps YOU keep track and helps Codex manage context window limitations.”

I realized my mistake: I was treating context window like infinite memory. It’s not.

Here’s what context window exhaustion looks like in practice:

1. Codex asks questions it should already know the answer to
2. Suggestions contradict earlier decisions in the same session
3. Responses become slower or more generic
4. "Compacting" messages appear in the output
5. Code changes conflict with previous changes

When any of these happen, you’re past the useful window. Time wasted from here is exponential.

How to solve it?

I implemented a two-part strategy: external memory files and session hygiene.

Part 1: External Memory Files

These markdown files persist across sessions. They’re your “save points” that Codex can read at the start of any session.

# Project Overview
E-commerce platform for digital products

## Tech Stack
- Frontend: Next.js 14, Tailwind CSS
- Backend: Next.js API routes
- Database: Supabase (PostgreSQL)
- Auth: Clerk

## Key Decisions
- Using server components by default
- Stripe for payments (not implemented yet)
- No custom CSS - Tailwind only

## Current Status
Auth complete, working on product catalog

## Code Style
- Use TypeScript strict mode
- Functional components only
- Server components when possible

## In Progress
- [ ] Product listing page with filters

## Up Next
- [ ] Product detail page
- [ ] Shopping cart

## Done
- [x] User authentication (Clerk)
- [x] Database schema for products
- [x] Admin product CRUD

# Architecture Decision Record

## ADR-001: Server Components by Default
Date: 2024-03-10
Decision: Use React Server Components for all pages unless interactivity requires client
Rationale: Better SEO, faster initial load, reduced bundle size

## ADR-002: Supabase over Firebase
Date: 2024-03-12
Decision: Use Supabase for database and auth
Rationale: PostgreSQL more suitable for e-commerce relational data, better query flexibility

The key insight from another Reddit user (kaancata):

“Create an architect.md file with instructions on how to be an architect, which is basically a ‘prompt engineer’ with project context. Then the agents.md/claude.md file, change log etc. These have instructions to always always be completely up to date.”

Part 2: Session Hygiene Protocol

I started following this workflow for every session:

1. Start: Read CLAUDE.md and architect.md
2. Context: Read TODO.md for current task
3. Work: Implement one feature/fix
4. Document: Update CHANGELOG.md
5. Track: Update TODO.md (check off completed)
6. Save: Commit to Git
7. Handoff: Summarize what was done (for next session)

At the end of each session, I create a handoff summary:

# Session Summary - 2024-03-15

## Completed
- Implemented product listing with pagination
- Added category filter
- Created ProductCard component

## In Progress
- Search functionality (started, not working)

## Issues Encountered
- Supabase query was slow, added index on products.category_id

## Next Session Should
1. Read this file and TODO.md
2. Debug search (check search_products function)
3. Add debouncing to search input

This 5-minute investment at session end saves 30+ minutes at session start.

The reason

Why does this work?

1. External files survive context resets

When Codex compacts its context window, everything in that session is compressed or lost. But files on disk persist. Your CLAUDE.md, TODO.md, and session summaries exist outside the AI’s memory.

2. Discrete work units are resumable

By completing one feature per session, you create natural breakpoints. Each session becomes a complete story with a clear beginning, middle, and end. When the next session starts, there’s no ambiguity about what’s done and what’s pending.

3. Git commits are checkpoints

Every commit is a recoverable state. If something goes wrong in a later session, you can always roll back. This makes context window management less stressful—you’re not risking hours of work.

4. Documentation as prompt engineering

The architect.md file doesn’t just record decisions; it provides context for future sessions. It’s like having a senior developer available to explain “why we did it this way.”

Here’s how the workflow looks visually:

┌─────────────────────────────────────────────────────────────────┐
│                     SESSION 1                                   │
├─────────────────────────────────────────────────────────────────┤
│ Read CLAUDE.md ──> Read TODO.md ──> Implement Feature A         │
│                         │                                       │
│                         v                                       │
│              Update TODO.md ──> Commit to Git                   │
│                         │                                       │
│                         v                                       │
│              Write Session Summary                              │
└─────────────────────────────────────────────────────────────────┘
                          │
                          v (context reset / new session)
┌─────────────────────────────────────────────────────────────────┐
│                     SESSION 2                                   │
├─────────────────────────────────────────────────────────────────┤
│ Read CLAUDE.md ──> Read Session Summary ──> Read TODO.md        │
│                         │                                       │
│                         v                                       │
│              Context Restored ──> Implement Feature B            │
│                         │                                       │
│                         v                                       │
│              Update Files ──> Commit ──> Summary                │
└─────────────────────────────────────────────────────────────────┘

Common mistakes I made

Mistake 1: Not creating documentation files

I assumed I’d remember everything. I didn’t. Sessions days apart became disconnected. Codex had no way to recover context.

Mistake 2: Sessions that were too long

I tried to implement three features in one session. By the third feature, Codex was already forgetting the first. Now I stop after one feature, commit, and create a handoff.

Mistake 3: Not committing code frequently

I went hours without commits. When context ran out, I had no clean checkpoint. Now I commit after every feature, even if small.

Mistake 4: Ignoring warning signs

When Codex started asking repetitive questions, I kept going. I should have recognized the context exhaustion and started a fresh session with updated documentation.

Mistake 5: Starting fresh sessions without reading state files

I’d open Codex and start typing without checking TODO.md or the session summary. This guaranteed lost context. Now reading these files is step one.

Summary

In this post, I showed how to manage Codex context window by treating it like limited working memory. The key point is that external markdown files are your persistent storage—they survive context resets and give every session a clean starting point.

The workflow is simple:

Create documentation files (CLAUDE.md, TODO.md, architect.md)
Work in discrete, commit-able units
Update documentation at session end
Always commit before context fills
Read state files at session start

What used to be 45 minutes of re-explaining is now 2 minutes of reading. The context window limitation becomes a workflow constraint, not a productivity blocker.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Reddit Discussion - What's the best way to use Codex?

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!