# Preserving Context When Moving from ChatGPT to Codex CLI

> Source: <https://dev.to/vvbogdanov/preserving-context-when-moving-from-chatgpt-to-codex-cli-bpl>
> Published: 2026-06-30 07:48:26+00:00

A lot of useful technical work starts as a conversation.

Maybe you are exploring an architecture decision in ChatGPT. Maybe you are debugging an idea before touching the codebase. Maybe you are asking broad questions first, then moving into a local development workflow once the direction is clear.

That handoff is often awkward.

The context starts in ChatGPT, but the implementation happens somewhere else: a terminal, an editor, a local agent, or a repo-specific workflow.

For me, that "somewhere else" is often Codex CLI.

So I built a small bridge:

```
npx chatgpt2codex https://chatgpt.com/share/<id>
```

`chatgpt2codex`

imports a shared ChatGPT conversation into a local Codex CLI session attached to your current project directory.

GitHub: [https://github.com/vv-bogdanov/chatgpt2codex](https://github.com/vv-bogdanov/chatgpt2codex)

npm: [https://www.npmjs.com/package/chatgpt2codex](https://www.npmjs.com/package/chatgpt2codex)

ChatGPT share links are useful for handing context to another person, but they are not directly useful to local tooling.

If I have a long conversation that contains design notes, constraints, tradeoffs, and implementation ideas, I do not want to manually copy pieces of it into a new Codex thread.

I want the local coding agent to resume from the conversation as if it had been part of the local workflow from the beginning.

That is what this tool tries to do.

Given a public ChatGPT share URL, `chatgpt2codex`

:

By default, it attaches the imported session to the current directory:

```
npx chatgpt2codex https://chatgpt.com/share/<id>
```

You can target another project directory with:

```
npx chatgpt2codex https://chatgpt.com/share/<id> -C /path/to/project
```

And you can preview the import without writing anything:

```
npx chatgpt2codex https://chatgpt.com/share/<id> --dry-run
```

The tool is intentionally conservative.

If a Codex session already exists for the target project directory, it exits with an error instead of overwriting anything:

```
A Codex session already exists for /path/to/project.
Use --force to replace it.
```

If you do want to replace the existing imported session, use:

```
npx chatgpt2codex https://chatgpt.com/share/<id> --force
```

There are also options for overriding the imported title and Codex home directory:

```
npx chatgpt2codex https://chatgpt.com/share/<id> \
  --name "Architecture discussion" \
  --codex-home ~/.codex
```

The first version wrote a Codex session file, but that was not always enough for Codex to pick it up in the resume flow.

Modern Codex builds use both rollout JSONL files and local SQLite metadata. So the current release writes the session file and also indexes the thread in Codex's local `state_5.sqlite`

database when that database exists.

It also uses Codex-visible session metadata, so the imported conversation appears as a normal CLI-originated thread rather than being filtered out.

That was the main lesson: for local agent tools, "write the file" is often only half the integration. The rest is making sure the surrounding state agrees with it.

ChatGPT share pages and Codex local session files are not official public import APIs.

Because of that, I kept the implementation small and pragmatic, with tests around the parts most likely to break:

`--force`

The tool requires Node.js 22.13.0 or newer because Codex's local SQLite index is important for the current workflow.

This is not a big framework or a new platform.

It is just a small CLI tool that closes a specific gap:

``` php
ChatGPT conversation -> shared URL -> local Codex session
```

That is enough to make the handoff from exploration to implementation feel much smoother.

If you use Codex CLI and sometimes start your thinking in ChatGPT, I would love to hear whether this fits your workflow.
