Second Brain With Codex: Reuse Notes and Save Progress

A second brain for Codex is a maintained set of project notes, instructions, and checkpoints that you explicitly ask it to use. Start with one project, give Codex the relevant files, and save what changed before the session ends. fenbs can hold the shared decisions and progress, so the work remains available when you move to another supported assistant.

The goal is a better starting point for the next task. A useful note tells Codex why something exists, which source is authoritative, or what still needs checking. Copying all your conversations into a folder gives it more text without necessarily answering those questions.

How do you start with a small, useful record?

1. Choose one active task and collect its current requirement, relevant source notes, and any approved decisions.
2. Write a short project overview that points to those files and explains what the project is trying to achieve.
3. Put stable working instructions in the project instruction file and changing status in a separate checkpoint.
4. Ask Codex to read the overview and relevant notes, then summarize the goal, constraints, and next action before editing.
5. Review the work and update the checkpoint with evidence, unresolved issues, and a concrete next step.

For example, say you are improving a scheduling page. Start with its approved behavior, the relevant code location, and the outstanding test. Leave unrelated product research out of the initial packet. You can add another note when the task actually needs it.

Our Codex overview covers the coding assistant. Here the focus is the durable information you maintain around it, whether you work alone or hand the task to someone else.

Which instructions should stay stable?

Official OpenAI documentation↗ (opens in a new tab) explains that Codex reads AGENTS.md files as project guidance, with instructions discovered along the project path. Use that file for how work should be done: the relevant commands, important boundaries, and where the project record lives. Check which instructions apply in the directory where you begin.

Keep the file readable enough that a person can check it. A rule such as “Record which checks ran and their results” is actionable. A statement such as “Make everything high quality” gives little help when Codex has to choose what to do next.

Before editing, read the project overview and current checkpoint.
Open the source notes relevant to the requested task.
Keep approved decisions distinct from suggestions.
Follow the repository rules for files, commands, and publishing.
Report checks actually run and any work not verified.
Before stopping, save a checkpoint with the next concrete action.

Avoid using instructions as a daily status log. “The migration is waiting for approval” belongs with the current task; “Ask before changing production data” is a continuing rule. When the two are mixed, yesterday’s status can look like a permanent constraint.

How should Codex choose the notes it reads?

Give it a small map, not an instruction to read everything. The overview should name the project goal and point to notes by purpose: requirements, source research, earlier decisions, and the current checkpoint. Ask Codex to open the material that matters to the task and explain why.

Require source references for important claims. If the code and a note disagree, ask Codex to flag the conflict and identify what needs verification. A confident summary is less useful than a precise account of the evidence and the gap.

This is one practical application of an AI second brain. For choosing a repository layout rather than a Codex routine, see the GitHub second-brain guide.

What should you save when a session stops?

Save enough for a new session to continue without reconstructing the chat. Name the task, its current state, the files affected, and the exact next action. Separate what was implemented from what was tested, and distinguish a failed check from a check that never ran.

Save a checkpoint for the next session:
- Goal and current task
- Files changed and why
- Checks run, with actual results
- Checks not run and remaining uncertainty
- Decisions waiting on a person
- Any process still running
- The first action to take next time
Do not describe unverified work as complete.

For the scheduling example, “Time-zone fix done” is too broad. “Converted display times in the page; the regression check for the fall clock change is still outstanding” is a useful handoff. It points to the next action without hiding the unfinished verification.

Keep one current checkpoint and preserve older evidence where your project normally keeps it. If you use fenbs for this record, save the task state and project Where we left off there. The AI handoff guide explains the transition between sessions.

How do you keep saved context accurate?

Treat a note update as part of the change you review. Check whether a new conclusion has evidence, whether the old instruction still applies, and whether the note makes its scope clear. A decision for one page should not quietly become a rule for the whole application.

If a note is wrong, correct the underlying record. Repeating a correction in chat leaves future sessions exposed to the same old file. Mark a replaced decision as replaced and point to the current one, keeping the reason available when it helps explain the design.

Give the assistant only the material appropriate for the task and the access you intend. Keep passwords, tokens, and private customer information out of general project notes. Instructions about careful behavior do not substitute for the actual access controls on a file or connected service.

How to do this with fenbs

1. Create a free account and add the project you want Codex to continue across sessions.
2. Add the active tasks and link the useful source files or reference pages. Write the current state without copying the full chat.
3. Record the rules and decisions people have agreed. Keep proposals open until a person decides.
4. Connect Codex using its guide on Integrations, then ask it to read the project context at the start of each session.
5. Before stopping, ask it to save progress on the tasks it touched and update Where we left off, including checks and the next action.

Codex supports MCP, a standard way for an assistant to use outside tools; OpenAI’s MCP documentation↗ (opens in a new tab) explains the supported connection and authentication options. Follow the fenbs setup guide for its browser sign-in rather than putting credentials into a note.

fenbs is free for one person, no credit card. It is not the right fit if you need a custom document search engine or only want local reference files. It keeps project work, decisions, lessons, and checkpoints; your source documents can remain in their existing homes.

How can you tell whether the setup works?

Start a fresh session and ask Codex three questions: what is the task trying to achieve, which decision constrains it, and what should happen next? Check its answers against the actual sources. This tests the record you saved, rather than the previous conversation still being available.

Fix the smallest gap you find. Add a missing source link, clarify an ambiguous checkpoint, or remove a stale instruction. The second-brain topic hub covers broader systems, but a few reliable notes are enough to make this routine useful.