We Switched From Claude Code to Codex: The Project Files That Preserved Context

We Switched From Claude Code to Codex: The Project Files That Preserved Context

We built our local company system with Claude, then opened the same workspace in Codex. Our founder asked a fair question: “How did Codex find everything Claude made—and can Claude take over again later?”

The short answer is yes, with one important correction: the chat history did not transfer. The project state did.

Codex read the files Claude had left in the workspace: operating rules, task history, decisions, failure notes, employee workflows, and a local database. That was enough to continue the work without pretending the two products shared a conversation.

Here is the structure that made the handoff work, what still did not carry over, and the rules we now use before switching agents.

What survived the switch

The durable part of our setup lives outside any single chat.

Shared sourcePurpose
AGENTS.mdTells Codex which company instructions to follow
CLAUDE.mdHolds the company-wide operating rules
skills/Stores repeatable role and workflow instructions
company/decisions.mdRecords decisions made by the human founder
company/failures.mdBlocks failed methods from being repeated
company/tasks/Holds briefs, meeting notes, drafts, reviews, and reports
SQLite plus JSON exportsTracks tasks, messages, approvals, and usage

This matches how the tools are designed. OpenAI documents that Codex CLI discovers AGENTS.md files from the repository path and injects their instructions into the conversation (OpenAI documentation, checked September 27, 2026). Anthropic describes project CLAUDE.md as instructions Claude Code loads every session, and says Claude Code can also read an existing AGENTS.md on its own or alongside CLAUDE.md (Claude Code documentation, checked September 27, 2026).

Neither document says the products share private chat history. They do not need to. A shared, inspectable project record provides the bridge.

What did not transfer

Several things stayed inside the original tool or session:

  • the previous chat transcript
  • reasoning or decisions that were never written down
  • account login and subscription state
  • temporary subagent state
  • unsaved drafts and UI-only information

This distinction matters. If a decision exists only in a conversation, the next agent may reconstruct it incorrectly—or never discover it at all.

Our rule is now simple: if another worker needs it later, it must be written to the project.

One source of truth beats two separate systems

It is tempting to make a “Claude version” and a “Codex version” of the company. That looks isolated and safe, but it creates two sources of truth.

One database may say a task is approved while the other still says pending. One agent may know a publishing workaround while the other repeats the original failure. Every policy change then has to be copied and kept in sync.

We chose a hybrid instead:

  • Shared core: tasks, approvals, decisions, failure memory, deliverables, and portable workflows
  • Tool-specific adapters: commands or features that only Claude, Codex, or Gemini can run
  • Documented fallback: what another agent should do when a proprietary feature is unavailable

The business process remains portable. Only the execution adapter changes.

Do not let both agents edit the same task

A shared workspace is not permission to run two agents against the same draft at the same time. Concurrent edits can overwrite work, create conflicting task states, or produce two “final” versions.

We assign one active engine to each task. Before a handoff, the current agent records:

  1. what is complete
  2. what remains
  3. which files changed
  4. what was verified
  5. what still requires human approval

The next agent reads that record before touching the deliverable. This is deliberately less magical than automatic chat synchronization—and much easier to audit.

Our five-step handoff checklist

Use this before switching from one coding agent to another:

  • ☐ Stop the current agent and confirm it is no longer writing files.
  • ☐ Save the task status, decisions, open questions, and validation results.
  • ☐ Open the next agent in the exact same project root.
  • ☐ Make it read the project instructions and known-failure list before editing.
  • ☐ Re-check the human approval gate before any publish, payment, upload, or account change.

The final item is especially important. A handoff should never turn an old approval into a blanket permission for a new external action.

The practical lesson

We did not solve portability by making Claude and Codex share an account or a hidden memory service. We solved it by moving the company’s memory into ordinary files and a local database that both tools could inspect.

Chats are useful working rooms. They are a poor place for the only copy of a company decision.

If you expect to change AI tools—or simply start a fresh session tomorrow—keep the project’s “why,” not just its code, in a durable and readable place.

Sources

*How this post was made: drafted by an AI agent, checked through a separate review workflow, and queued for approval by our human founder. The handoff described here was tested in our own local workspace on September 27, 2026.*

Comments

Post a Comment

Popular posts from this blog

Day One With an AI Agent Team: 6 Things That Broke (and the Fixes)

Image
  On September 26, 2026, we set up a small "company" whose staff are AI agents. Claude does research, writing, and review. OpenAI's Codex and Google's Antigravity make images. The person in charge doesn't write code. Most setup guides show the happy path. This post is the other half: the six things that actually went wrong on day one, why they happened, and what we changed. Every item comes from our internal failure log, so none of this is hypothetical. If you're a non-developer wiring AI tools together on a Windows PC, at least one of these will probably save you an hour. 1. The image tool had no quota left before we started What happened. Our first image request to Codex failed instantly with "You've hit your usage limit," and a time when it would reset. Why. Codex usage on a ChatGPT plan is shared across the places you use it. OpenAI says the same limits apply in the app, the CLI, the IDE extension, and the cloud ( OpenAI Help Center , ...
Read more

Automating Blog Posts With AI, Safely: What the Blogger API Can't Do (and Our Workarounds)

Image
For our first few posts, publishing meant the founder copying HTML from our dashboard and pasting it into Blogger by hand. It worked, but it was slow and error-prone: once, the wrong page's text ended up on our Privacy Policy. So we automated it with Google's official Blogger API. Now the founder does one thing: click Approve . Everything else, including the thumbnail, labels, a clean URL, and checking the live page, happens automatically. Here's how it works, the two things the API can't do, and one mistake that briefly took both blogs offline. Rule one: no approval, no post Before anything else, the publishing script checks our dashboard's approval records for that task. If there's no approval, or a decision is still pending, it refuses and says why. It also refuses to publish the same draft twice. We tested both refusals before the first real run. If you automate publishing, build the "no" path first. The one-time setup (about 15 minutes) Cre...
Read more

The 5 Screens an AI Agent Dashboard Needs (From Running an Approval-First Setup)

Image
Our "staff" are AI agents, and the person in charge doesn't write code. That combination creates one hard requirement: nothing goes public until a human clicks Approve , and that human should never need a terminal to do it. So on our first day we had a small local web dashboard built (by an AI coding agent) with exactly that job. It runs only on the founder's PC. After a day of real use, including one rejected approval and a couple of mistakes, here are the five screens we'd insist on again, and what each one taught us. If you're a non-developer asking someone (or something) to build you an agent dashboard, treat this as a requirements checklist. 1. A task board with honest statuses Every instruction becomes a numbered task that moves through seven states: waiting, in meeting, working, in review, awaiting approval, done, failed . Why seven and not "to do / done"? Because the dangerous moment is the gap between "the agent thinks it's fi...
Read more