How I Make Claude Code and Codex Share One Worklog

Diagram of a shared worklog folder tree: year, month and day folders, each holding one small file per work record from Claude or Codex.

When two AI assistants edit the same folder, neither one knows what the other just did. That isn't a bug in either tool. Anthropic's documentation for Claude Code says it plainly: "Each Claude Code session begins with a fresh context window" (Anthropic, Claude Code memory docs). Anthropic's engineering team describes the same starting point for long-running agents: "each new session begins with no memory of what came before" (Anthropic Engineering, long-running agents).

I'm an architect who designs buildings, not a professional developer. I run Claude Code, Codex and a few other assistants on one shared project folder, and that folder isn't a git repository. There's no commit history to tell me, or them, who changed what. So I built a shared worklog to fill that gap. Below is what it looks like, the two commands that drive it, and the rules that keep it honest.

Key Takeaways

  • Each Claude Code session starts with a fresh context window, so another assistant's work is invisible unless it's written down somewhere both can read.
  • One shared log tree, organized by year, month and day, with one file per record, replaces separate per-AI log files.
  • Before a medium or large task, each AI reads what the other AIs recorded in the last three days. After the task, it adds one record.
  • Records are never edited. A correction is a new record.
  • A missing log entry doesn't prove nothing changed. When the log and the files disagree, the files win.

Why don't CLAUDE.md or AGENTS.md files share memory between two AI tools?

Instruction files tell an assistant how to behave but never what happened yesterday, so CLAUDE.md and AGENTS.md cannot pass the history of one session to the other tool.

Claude Code reads a CLAUDE.md file "at the start of every session" and treats it "as context, not enforced configuration" (Anthropic, Claude Code memory docs). On the Codex side, OpenAI's documentation says "Codex reads AGENTS.md files before doing any work" (OpenAI, Codex AGENTS.md docs). AGENTS.md describes itself as "a simple, open format for guiding coding agents" (agents.md), and GitHub's Copilot coding agent also reads AGENTS.md, along with CLAUDE.md and GEMINI.md files (GitHub Changelog, August 2025). That describes the products at the time of writing; these docs are live and change often.

These files are where I keep standing rules, including the rule to use the worklog. I think they're the wrong place for a running record of changes. A rules file is something you keep up to date. A history should only grow.

Instruction file (CLAUDE.md, AGENTS.md) Shared worklog
Purpose Standing rules for how an assistant should work A record of what each assistant actually did
When it's read Claude Code reads CLAUDE.md at the start of every session; Codex reads AGENTS.md before doing any work Before any medium or large task, each assistant reads the others' records from the last three days
How it changes Kept up to date as the rules change Only grows: new records are added, old ones are never edited
Who writes it I do; it holds the rules I keep for my assistants Each assistant, one record per task, under its own name

What do you need before you start?

You need one shared folder that two or more assistants edit, a way for them to run a small script, and an instruction file for each assistant; no git is required.

  • A folder that two or more AI assistants edit.
  • A way for those assistants to run a small script. Mine is written in Python.
  • An instruction file for each assistant (CLAUDE.md, AGENTS.md or similar) where you can state the worklog rules.
  • No git required. That's the point of the setup.

Step 1: How do you freeze the old per-AI logs?

Freezing the old per-AI log files on one cut-over date stops the history from splitting into separate places, and the old files are kept rather than deleted.

Before this setup, each of my assistants kept its own single log file that kept growing. On 2026-10-05 I froze those files: they're kept exactly as they were, and nothing writes to them anymore.

  1. Pick a cut-over date.
  2. Mark each old log file as frozen in your instruction files so no assistant appends to it.
  3. Don't delete the old files. They're still history.

Later I split those old logs into per-record copies inside the new date tree. Now all history can be searched in one place. The originals stay where they are.

Step 2: How do you build one shared, date-based log tree?

By the end of this step you'll have one place every assistant writes to.

The layout is worklog/YYYY/MM/DD/HHMM_{AI}_{title}.md. That means year, month and day folders, and one record per file. Every AI shares the same tree. A new assistant doesn't get its own log file; it writes into the same tree under its own name.

A single day in the tree looks like this (the titles are made up):

worklog/
└── 2026/
    └── 10/
        ├── 21/
        │   ├── 0915_Codex_rename-reference-images.md
        │   ├── 1340_Claude_rebuild-index-page.md
        │   └── 1702_Claude_fix-broken-links-in-index.md
        └── 22/
            ├── 0830_Codex_update-glossary-terms.md
            └── 1110_Claude_correct-index-page-record.md

I chose one file per record for a practical reason. In my view, it means two assistants writing at the same time never fight over the same file. Each one creates its own new file and leaves everyone else's alone. As of 2026-10-22, the tree holds roughly 2,900 files, counting the split copies of the old logs.

Step 3: What goes into a short record body?

A record only helps if the next assistant can scan it fast. Mine has four parts:

  • Scope and result: what the task was and how it ended.
  • Files: what was created, changed or deleted, or "no changes."
  • Evidence and verification: what was checked, and whether the work is verified.
  • What's left: open items and the next step.

That's all. I care more about a clear file list and a clear verification state than about a long narrative.

This is one record from the tree above, filled in. It's made up, too:

1340_Claude_rebuild-index-page.md  (a made-up example)

Scope and result: Rebuilt the index page so it lists every guide
in the folder. Done.

Files: Changed index.md. No files created or deleted.

Evidence and verification: Opened the page and checked that each
link points to an existing file. Verified.

What's left: Two links point to files that were renamed earlier.
Fix them next.

Step 4: How does an assistant read what the others did?

Before a medium or large task, the assistant runs the recent command and reads the records the other assistants wrote in the last few days, which is what actually stops context from getting lost.

The tool behind this is a small Python script with two commands. Before any medium or large task, the assistant runs:

python worklog.py recent --days 3 --exclude <its own name>

The recent command lists the records the other assistants wrote in the last N days. My rule sets N to three. The assistant skips its own entries because it already has its own context; what it lacks is everyone else's.

There's a published precedent for this habit. Anthropic's engineers describe a routine for long-running agents: "Start the session by reading the progress notes file and git commit logs" (Anthropic Engineering, long-running agents). Their setup had git. My folder doesn't, so the shared worklog stands in for the commit log. That article describes their setup. It doesn't prove mine works; it just shows the same idea.

Step 5: How does an assistant add a record when a task is done?

After finishing, the assistant adds exactly one record:

python worklog.py add --ai <name> --title "..." --body-file <file>

The add command takes the assistant's name, a title and a file holding the record body. It writes one new file at worklog/YYYY/MM/DD/HHMM_{AI}_{title}.md, stamped in Korean Standard Time, so every assistant's entries use the same clock.

Not every task gets a record. Trivial one-shot jobs, like a translation or checking the time, don't. Anything another assistant needs to know, such as a decision or a judgment call, does.

This matches a broader pattern Anthropic describes for agents: writing "notes persisted to memory outside of the context window" (Anthropic Engineering, context engineering). Their multi-agent research system has agents "store essential information in external memory before proceeding to new tasks" (Anthropic Engineering, multi-agent research system).

Step 6: Why never edit a record, and how do you correct one?

A written record is never edited; a correction goes in as a new record that points at the old one, like the correct-index-page-record example in the tree above.

The idea isn't new. Michael Nygard's essay on architecture decision records says "Numbers will not be reused," and for a reversed decision, "keep the old one around, but mark it as superseded" (Nygard, Documenting Architecture Decisions). Martin Fowler's description of event sourcing makes the same move at a larger scale: "Capture all changes to an application state as a sequence of events" (Fowler, Event Sourcing).

For my setup, the practical benefit is trust. If records can be rewritten later, the history stops being a history.

Step 7: Why trust the files over the log?

The absence of a log entry is not proof that nothing changed, so when the log and the files disagree the files win.

An assistant can skip a record, finish a task halfway or be interrupted. The log is a strong hint about what happened, not a guarantee. So when something looks off, the assistant checks the real files instead of reasoning from the log alone.

What mistakes break a shared worklog?

The mistakes that break the system are writing records without reading them, keeping one big shared file, editing old records and trusting the log over the files.

Only writing, never reading. If assistants add records but don't read the others' records first, the log becomes an archive nobody consults. Make the read step a stated rule in each instruction file.

One big shared file. A single growing file is where two writers can collide. Giving each record its own file avoids that, for the reason in Step 2.

Editing old records to "clean up." It feels tidy, but it erases what someone else may have relied on. Add a correction record instead.

Treating the log as the truth. The files are the truth. The log helps you know where to look.

Frequently Asked Questions

Do Claude Code and Codex remember what the other one did?

Not that I've found. The Claude Code docs say each session starts with a fresh context window, and both tools read their instruction files when they start. I didn't find Codex documentation on cross-session memory, so I won't make a claim about Codex either way. A shared log that both can read is how I bridge the gap.

Can I do this without git?

Yes. My folder isn't a git repository, and that's exactly why I built the date tree. If you do use git, its history already answers "who changed what," though a short record still explains why.

Should a worklog be one file or many?

I use many: one file per record. It keeps simultaneous writers out of each other's way and makes each record easy to find by date and author.

What if an assistant writes a record that is wrong?

Correct it with a new record instead of editing the old one. The old record stays as written and the new one points at it, so the history still shows what each tool believed at the time.

The takeaway

A shared worklog won't make any assistant remember more. What it does is give every assistant, at the start of every session, one place to read what the others did. If you set up only one piece of this, make it the read-before-you-start step.

Related guides

About the author

JH-A is an architect who designs buildings, not a professional developer. JH-A runs Claude Code, Codex and a few other AI assistants on one shared project folder that isn't a git repository. The worklog in this post is how JH-A keeps track of what each of them changes there.

This post was drafted with the help of AI writing tools, based on my own setup and notes.

Sources

Hero image: original diagram made for this post.

Comments

Post a Comment

Popular posts from this blog

How to Clean Messy Excel and CSV Data With AI Without Breaking Your Totals

Image
A cleanup that strips currency symbols and adds everything into one column cannot tell you whether it was right. On a 60-row vendor file I tested on November 15, 2026, that shortcut reported 21,748,113.34 as a single total. The file's real USD total is 51,464.59. The working method separates USD from KRW into two columns. It parses dates with an explicit format list, removes duplicates by invoice number, and compares a checksum against the untouched source. Key Takeaways A currency-blind cleanup reported 21,748,113.34 for a file whose real USD total is 51,464.59, an overstatement of 21,696,648.75. Comparing whole rows as text removed 0 of the 4 duplicate rows. Keying on invoice number removed all four and cut USD by 238.75 and KRW by 2,480,000. One date format read 19 of 60 rows. A three-format parser read 58 and rejected the 2 impossible dates instead of guessing them. DATEVALUE() read only 25 of the 58 valid dates in a Korean-locale sheet, so 33 rows would have vani...
Read more

REA for AI Agents: What It Can Prove About an App

Image
REA, short for Reverse Engineer Anything , gives an AI agent tools to inspect software and collect evidence about how it works. It can help answer a concrete question, such as where an export file is created or which function handles a button. The useful part is being able to check the answer. A confident explanation alone leaves you guessing whether the agent found something in the app or filled a gap. For this article, we created a tiny JavaScript example and inspected it with REA. The tool found the file connection, reported no parsing failures, and still left a return value unresolved. That combination is a useful lesson in reading AI analysis. Key Takeaways REA connects an AI agent to software inspection tools. The agent turns their results into an explanation. Start with one feature and a specific question. A complete static scan can still contain unknown values. Keep code ...
Read more

TrendRadar AI: Start With a Smaller News Brief

Image
If keeping up with your industry means checking the same sites each morning, TrendRadar can gather and filter their headlines into a report. Start with a few RSS feeds and clear keyword rules, then add AI features when you know what you want them to do. sansan0’s TrendRadar is an open-source news and trend monitor. This article covers that project, including a small test of its English keyword matcher. The useful first goal is a brief you would actually read: relevant sources, a manageable topic and links worth opening. Key Takeaways TrendRadar combines trending lists and your chosen RSS feeds, with optional AI filtering, translation and analysis. Plain keywords match parts of words. In our small test, AI also matched rail and training . The starter rules below use whole-word matches and one exclusion. They were checked with nine invented English headlines. Collection, AI analysis and notification delivery need separate setup. Our trial tested the keyword module, rather t...
Read more