Codex CLI Export Chat: Save a Useful Development Handoff

To export a Codex CLI chat, wait for the current turn to finish, then use /export to save or copy the conversation as Markdown. Keep that transcript as a reference, and write a separate development handoff that explains the actual code changes, checks, and remaining work.

A transcript tells someone what was discussed; a handoff tells them where to start. Tools like fenbs keep the reviewed project record outside the terminal, so another assistant or teammate can continue without reading the entire conversation.

How do you export a Codex CLI conversation?

1. Let the current turn finish so your export includes its completed response.
2. In the interactive Codex chat, type /export and choose Copy to clipboard or Save to file.
3. Alternatively, type /export session.md to save directly to a Markdown file. Choose a filename that identifies the project and task.
4. Open the resulting file, check its beginning and end, and review the content before sending it to anyone.

These are the supported steps in the official OpenAI developer commands documentation↗ (opens in a new tab). Check the commands available in your installed CLI if its interface differs. Do not substitute an imagined shell command such as codex export for a documented interactive command.

Save the transcript somewhere appropriate for the project. A file in a repository may become part of a later commit, so check what it contains before adding it to version control. If you meant an account conversation in the browser, use the separate guide to exporting ChatGPT chats.

Which kind of output are you actually saving?

Several Codex records look like an export but serve different purposes. Name the artifact accurately when you share it, so the recipient understands what evidence it can provide.

For non-interactive runs, codex exec supports -o or --output-last-message for the final response, while --json emits a JSON Lines stream, meaning one structured event per line. These capture a run’s output; they do not retroactively export an earlier interactive conversation. See OpenAI’s non-interactive mode documentation↗ (opens in a new tab) for those distinct options.

Local session storage is also different from a handoff. Avoid treating application records as an interchangeable transcript format or copying an entire configuration directory to a colleague. For more command context, see Codex CLI commands.

What belongs in a useful development handoff?

Start with the task’s current state, then include enough detail to check it. A long list of assistant messages is less useful than a short account of what exists in the repository and why it exists.

• Goal and scope: what the requested change should do, including any boundaries the person set.
• Changed files: paths and the purpose of each meaningful change; identify uncommitted work explicitly.
• Decisions: the approach the person approved, the reason, and any alternatives still awaiting a choice.
• Checks: the exact check, its result, and what was not checked. Separate a planned test from a completed test.
• Next action: the smallest useful step, its owner when known, and any blocker.

For example, a handoff might say that form validation was added, unit checks passed, and mobile keyboard behavior still needs a person to inspect it. That last clause prevents the next assistant from assuming the screen was fully verified. Keep a pointer to the transcript for questions that need more background.

A shared AI handoff in fenbs gives that concise progress record a place the next connected assistant can read.

How do you verify the handoff against the code?

Ask Codex to draft the handoff, then compare it with the repository yourself. Review the changed files and the current difference from the starting point. If a commit exists, record its actual identifier; if it does not, say the changes are uncommitted.

Check that each named file exists and that the described behavior matches the change. A transcript may include an approach that was tried and later removed. Preserve the final state and explain a discarded approach only when that knowledge prevents someone repeating the same mistake.

Read test output before claiming success. A passing command may cover only one package or a narrow behavior. Write that scope down, alongside any skipped checks or unresolved failures; our Codex CLI best practices guide covers the wider working habits.

What should you remove before sharing the transcript?

Review prompts, command output, pasted configuration, and file excerpts for secrets or information the recipient should not receive. A conversation can reveal private project names or customer details even when the final code is safe to share.

Make a reviewed sharing copy and remove unnecessary sensitive material from that copy. Keep enough context for the recipient to understand the work, and label substantial omissions. Exporting a conversation does not itself establish permission to distribute everything inside it.

How do you start a new chat without losing the work?

Prepare the handoff before starting fresh. The CLI’s /new command starts a fresh chat; opening that chat does not mean its assistant has read your exported file. Give it the reviewed handoff and identify the repository state it should inspect before changing anything.

Keep conversation continuity separate from file isolation. If you need another checkout for the next approach, follow the Codex CLI worktree guide. For the broader problem of moving work between sessions or assistants, browse the AI handoffs library.

How to do this with fenbs

1. Create a free account, then add the project whose development work you want to preserve.
2. Add or update its tasks with the change, relevant file paths, actual test results, and unfinished checks.
3. Record the person’s approved choices in Decisions and rules. Leave unresolved choices open for the person.
4. Connect Codex CLI using the setup guide, and have the assistant save task progress and Where we left off before it stops.
5. At the next session, ask the connected assistant to read the project context first and verify the repository state before continuing.

fenbs does not export your Codex conversation or read your terminal history. If all you need is a one-time Markdown transcript, the CLI export is enough; fenbs is useful when the outcome needs to remain available across people and assistants.