A behind-the-scenes log from Zip Yacht: how we got Anthropic’s Claude and OpenAI’s Codex exchanging work we could actually verify.
On a boat, a handoff matters. A job can sound finished over the radio while the next person is still waiting for the part, the paperwork, or the instruction that makes it usable.
We ran into the digital version while building Agent OS, the operating system behind my work across Zip Yacht and our other ventures. Claude and Codex could each get useful work done. Getting them to share an accurate picture of that work took more effort.
On September 24, 2026, we completed a verified file exchange in both directions. Here is what it took—and what we have deliberately left switched off.
Watch the 5-minute overview
Watch on YouTube · 5:12
Listen to the deeper discussion
A 21-minute audio deep dive into the roles, verification steps and limits behind this handoff.
Download the audio (MP3) · 21:47
AI-generated video and audio overviews created with Google NotebookLM from this article. The written build log below is the primary record of the test and its limits.
Two capable tools still need a clear division of work
Our arrangement gives Claude responsibility for coordinating priorities and producing the single morning brief. Codex handles bounded local work: files, scripts, backups, technical checks, and independent verification. I retain the decisions about publishing, spending, credentials, and irreversible changes.
Those are the roles we chose for this workflow. This is our use of tools from two frontier AI labs, not a partnership or shared product announced by the labs themselves.
The aim is practical: let each assistant do useful work without making me the full-time messenger between them.
First, we had to agree on what was true
We started with a candid review of the operating records. Some instructions described old agent roles. A work-order index said a job was waiting to start even though a result already documented why it was parked. An old article draft still appeared as an open publishing task.
The briefing exposed another important distinction. The local archive looked stale, but Claude checked the cloud routine and confirmed recent delivery in Gmail. A stale local folder was not proof that the morning brief had stopped. Two missing editions were identified separately and left as an unresolved issue.
We corrected the pointers, reconciled the work-order status, and later recorded the old draft’s reversible retirement. Before local changes, we saved originals. After writing, we checked the resulting files. That gave the next session a better starting point than another confident summary.
Then we fixed a small problem that kept coming back to me
The inbox analyst had asked me to clarify an email address even though the correct address was already in the canonical records.
We changed its instructions to check those records before asking, cite the source it used, and finish with a proposed owner, next action, and status. The analyst still only proposes work; it does not gain permission to send messages or execute tasks.
We tested the change on a copy of the original note in an isolated workspace. It used the correct address, cited the register, and stopped asking the unnecessary question. Running the unchanged note a second time produced no duplicate response or ledger entry. Only then did we apply the prompt change.
The shared folder had to earn our trust
Writing the same folder path in two conversations did not establish that both assistants could reach the same files. We first proved a manually initiated read through an approved local connection. Then we tested a dedicated Google Drive drop folder: Claude accessed it through its cloud connector, and Codex accessed it through Drive for desktop.
We confirmed the desktop account and the exact folder before writing anything. The folder carries handoffs and acknowledgments; it does not replace the canonical operating records.
- Claude wrote a test file. It included a unique test identifier, often called a nonce.
- Codex read the file locally. It checked the identifier, counted the bytes, calculated a SHA-256 fingerprint, and wrote an acknowledgment.
- Codex wrote a fresh return test. This used a new identifier.
- Claude fetched and checked both files independently. It recalculated the fingerprints and wrote its own acknowledgment.
- Codex read that acknowledgment back locally. The return file’s identifier and fingerprint matched.
The first test was 405 bytes; the reverse test was 577 bytes. Both matched across the two environments. The fingerprints gave us evidence that the same bytes arrived. They do not, by themselves, prove that a future instruction is sensible, authorized, or correctly executed.
We checked the safety net, too
A backup log saying “success” was not enough. Codex independently checked the remote backup commit, retrieved it into an isolated directory, checked Git’s object integrity, and compared 28 files with the live vault.
That comparison surfaced line-ending differences and an expected document change made after the backup. We recorded those limits rather than claiming a perfect byte-for-byte restore. The check established useful evidence about recovering the sampled vault content; it did not certify every application database or every disaster-recovery scenario.
What is working—and what is still off
The shared drop folder is proven in both directions with manual pickup. Each side can read a file, check it, and return an acknowledgment through the agreed route.
Automatic pickup and return notifications remain off. We have not created a watcher, polling job, or scheduler for this handoff. The proposed morning-brief failure alert is also not built. Those are separate decisions and tests.
There is still a person initiating the work. The milestone is that we have demonstrated a shared transport with receipts, clear ownership, and an honest record of its limits.
Why we are sharing this through Zip Yacht
Yacht operations depend on clear responsibility and useful handovers. The same discipline helps when AI assists the office: identify who owns the job, keep the record current, preserve a rollback, and check what the next person actually received.
We are documenting this as we build it. The useful question is whether the system reduces the work I have to repeat, remember, and chase.
Our next milestone is to test a bounded work order through this proven route and verify the result. If we later enable automatic pickup, that will deserve its own evidence—not an assumption carried forward from today’s file test.
What handoff in your marine business would you want to make more dependable first: inquiries, crew paperwork, maintenance follow-up, or the daily office brief?
Build log: September 24, 2026. Based on our recorded tests and acknowledgments. Manual file transport verified; unattended operation not claimed.