›_ Codex Issues
Codex Issues / #20115

Feature request: archive Codex conversations to a project folder

Open 💬 3 comments Opened Apr 29, 2026 by birdfly

Summary

Please add a way to archive or associate a Codex conversation with a specific local project folder/workspace, and export the full conversation history as a project artifact.

Problem

For long-running work, the conversation itself becomes part of the project record: decisions, review notes, rationale, follow-up tasks, and references to generated files often live in the thread. Today, users can create a manual summary file, but the Codex conversation remains separate from the project folder and cannot be moved, indexed, or exported as a first-class project artifact.

This makes it harder to:

  • hand off work to another person,
  • audit why certain changes were made,
  • resume a project weeks later,
  • keep multiple project conversations organized,
  • preserve a complete record of the discussion alongside the files it produced.

Requested functionality

It would be useful if Codex supported one or more of the following:

  1. Assign or move a conversation to a local project folder/workspace.
  2. Export a full conversation to Markdown, JSON, or PDF from the app.
  3. Generate and maintain a project-level conversation index, for example .codex/conversations/ or similar.
  4. Allow project-scoped search across prior Codex conversations.
  5. Include links from exported conversations to files created or edited during the thread.

Expected user experience

Example flow:

  1. User opens a Codex conversation used for a project.
  2. User selects Archive to project... or Export conversation....
  3. Codex lets the user pick the workspace/project folder.
  4. Codex writes a durable artifact such as:
  • .codex/conversations/<date>-<title>.md
  • .codex/conversations/index.json
  1. The project can later be reopened with the conversation history discoverable from that project context.

Why this matters

This would make Codex more useful for professional long-running projects where the conversation is part of the working record, not just a transient chat. It is especially useful for code reviews, legal/document review workflows, research projects, and multi-stage implementation plans.

Privacy / control considerations

The feature should be user-initiated and local-first. Users should choose exactly which conversation is exported and where it is saved.

View original on GitHub ↗

3 Comments

Lee-take · 3 months ago

I want to add one related workflow that is not only about archiving an existing project conversation after the fact.

In many real projects, the conversation starts before the project folder exists.

Typical flow:

  1. I open a new Codex conversation to explore a new project idea.
  2. In that conversation, I work with Codex to clarify:
  • project goals and scope
  • the proposed framework / folder structure
  • required source materials
  • decisions already confirmed
  • open questions
  • first execution roadmap
  1. Only after this planning phase do I create the actual project directory/workspace.
  2. At that point, the early planning conversation is disconnected from the new project, even though it contains the most important project context.

So the requested feature is not just "export this conversation to a folder", but also:

  • Promote this conversation into a new project/workspace
  • Attach this pre-project conversation to an existing project/workspace
  • Generate a project starter package from the conversation

Suggested UX:

  • Add an action such as Create project from conversation... or Attach conversation to project...
  • Let the user choose or create a local project directory.
  • Before writing files, show a preview of the generated project context.
  • Generate files such as:
  • PROJECT_CONTEXT.md
  • DECISIONS.md
  • MATERIALS_NEEDED.md
  • ROADMAP.md
  • OPEN_QUESTIONS.md
  • optionally AGENTS.md
  • Link the generated context back to the original conversation/thread.
  • Make future Codex sessions opened in that project aware of the imported context.

Why this matters:

The highest-value planning often happens before a repo or folder exists. Without a way to promote that conversation into the later project, users either lose context, manually summarize/copy-paste, or start the project with weaker continuity.

This would make Codex feel much more natural for non-trivial project initiation workflows: research first, structure second, project directory third, execution fourth.

Lee-take · 3 months ago

Thank you. I would like to add a short follow-up because I also tried submitting this through OpenAI Support / feedback.

The support response was helpful, but it appears to be an AI-assisted support reply. It confirmed that Codex and ChatGPT conversations are currently separate and that there is no built-in way to promote a Codex conversation into a Codex project/workspace. It also suggested the current workaround: ask Codex to generate files such as PROJECT_CONTEXT.md and DECISIONS.md once the folder exists.

That workaround is exactly what we are doing today, but the point of this feature request is to make that workflow first-class inside Codex.

Could a Codex product or engineering maintainer please confirm whether this GitHub issue is the right place for this request to be tracked?

If there is a better channel for Codex Desktop / Codex App product feedback, I would appreciate being pointed to it.

The core workflow remains:

  • Planning conversation starts in Codex before a project folder exists.
  • That conversation contains goals, decisions, constraints, source-material requirements, and the first roadmap.
  • Later, the user creates a local project/workspace.
  • Codex should provide a way to promote or attach that planning conversation to the new project, ideally generating project context files and preserving a link back to the original conversation.

This is a real workflow gap for long-running professional projects, not only a request for generic export.

JoelMTaylor · 1 month ago

Our local proof of concept adds a little implementation evidence. We generated a project catalogue and one Markdown file per conversation, with optional subject, tags, lifecycle label, summary, and evidence link. We also linked each catalogue entry back to the live Codex editor and its recorded workspace.

For our own readable exports, we included user and assistant messages while omitting tool calls, command output, reasoning records, and system/developer instructions. This worked for the sessions tested, but it is only a best-effort filter over local files whose detailed schema we do not understand as a supported contract.

One additional design question raised by the experiment is whether a native export could identify its privacy/completeness profile explicitly, for example:

  • Readable: user and assistant messages only.
  • Audit: messages plus tool calls and tool results.
  • Complete/raw: lossless machine-readable conversation data.

I am not sure which of those profiles would fit Codex's product or privacy model. A documented distinction would help users understand whether an export is intended for reading, auditing, backup, or restoration.

The live-editor link was particularly useful in our catalogue. It currently depends on an extension resource we could not find documented as public, so a supported open session by ID command would complement this proposal without requiring exported files to understand Codex internals.