Add a durable project outcome ledger for multi-month work

Summary

Codex projects can run for three or four months and accumulate dozens or hundreds of threads. During that time, the valuable project record is not the transcript itself. It is the sequence of problems investigated, diagnoses reached, decisions made, solutions accepted, and results verified.

Codex should maintain a first-class, durable project outcome ledger that preserves those conclusions across threads and makes them reusable by both the user and future Codex tasks.

Problem

Thread titles usually describe the initial prompt. As a thread progresses, its scope and final result may change substantially. The final solution can be buried deep in the transcript under a title that no longer describes it.

Cross-project title and content search is useful when the user remembers an exact phrase, command, filename, or error message. In a project that has been active for several months, users often remember only:

• that a similar problem was solved before;
• the approximate product area;
• part of the reasoning or outcome;
• or that an earlier decision should still apply.

They may not remember the original thread title or any exact keyword used in the conversation.

A single dynamic title does not solve this. Renaming a thread to match its newest state can make an earlier solved subproblem less discoverable. Raw transcript export does not solve it either: it preserves everything without identifying what became durable project knowledge.

Example: a four-month project

Consider a product project that runs for four months and uses many Codex threads:

1. In month one, a thread starts as “Investigate intermittent sync failures.” After debugging, the actual cause is identified as a refresh-token race, and a specific recovery strategy is verified.
2. In month two, another thread changes the analytics event contract after several alternatives are rejected.
3. In month three, a release regression is fixed by restoring a configuration constraint discovered in an older thread.
4. In month four, a similar sync symptom returns.

At that point, the user remembers that Codex solved a related issue months ago, but not:

• which thread contained it;
• what the thread was originally called;
• whether the final cause was caching, authentication, or retry behavior;
• which alternatives were ruled out;
• or how the fix was verified.

The project contains the answer, but the product does not expose the answer as a durable project outcome.

Proposed capability

Add a project-level Outcomes, Decisions, or Project Knowledge view. Codex should suggest a new outcome entry when a thread reaches a meaningful diagnosis, decision, implementation result, or verified completion.

Each entry could contain:

• date and topic;
• problem or question;
• final diagnosis;
• accepted decision or solution;
• important alternatives that were rejected, and why;
• relevant files, commands, configuration, or external references;
• verification evidence;
• current status: active, superseded, reverted, or uncertain;
• source thread and direct link to the relevant turn;
• relationships to earlier outcomes that it confirms or supersedes.

Entries should be append-only by default. A newer decision should mark an older one as superseded rather than silently rewriting project history.

Suggested user experience

1. When a meaningful outcome is reached, Codex offers Save to Project Outcomes with a short structured draft.
2. The user can accept, edit, merge, or dismiss it.
3. The Project page exposes the accumulated ledger as a timeline and topic-based view.
4. Users can search it with natural-language questions such as:
   • “Where did we solve the recurring sync failure?”
   • “Why did we reject the previous analytics schema?”
   • “What was the verified localization release workflow?”
5. Results show the concise outcome first and link directly to the source thread and turn.
6. New threads in the same project can retrieve relevant accepted outcomes before proposing a solution, while still checking whether they are current.

The system should avoid creating an entry after every turn. It should focus on meaningful, reusable conclusions and provide user control over what becomes durable project knowledge.

Why this is different from memory

This is not only model memory.

Memory primarily helps Codex construct future context. A project outcome ledger is also a user-facing, inspectable project record. Users should be able to browse it, correct it, understand its sources, see when a decision was superseded, and deliberately reuse it.

It should be possible to use project outcomes without mixing them into unrelated projects or silently treating an old conclusion as current truth.

Why this is different from existing requests

• #24060 concerns keeping the current thread title aligned with an evolving conversation.
• #16672 implemented cross-project title/content search and result jumping.
• #18343 concerns global, project, hybrid, and thread memory scopes.
• #20115 concerns archiving or exporting full conversations as project artifacts.
• #36885 proposes a semantic overview of threads across projects.

This request is specifically for a durable, structured record of what a long-running project learned and decided, independent of how its transcripts are titled, searched, clustered, or exported.

Acceptance criteria

1. A project can accumulate structured outcomes across multiple threads over several months.
2. Every outcome links to source evidence in the original thread.
3. Users can inspect, edit, merge, dismiss, and supersede entries.
4. Natural-language retrieval works when the user remembers the meaning but not the original keywords.
5. New project threads can retrieve relevant accepted outcomes with provenance and status.
6. Manual thread titles and raw transcripts remain unchanged.
7. Project outcomes do not leak into unrelated projects.
8. Codex does not modify repository files or publish project information without explicit user action.

Environment

• Codex Desktop / ChatGPT desktop app
• Version observed: 26.803.61601
• macOS, Apple Silicon

The issue names no files, tests, or code entry points. Begin by mapping the existing project page, thread persistence, search or retrieval, and memory-scope implementations, then compare them with the acceptance criteria; done requires user-controlled, source-linked outcomes with status, natural-language retrieval, project isolation, and no implicit file or publication changes.