All News
DocumentationDeveloper Experience

OpenClaw Splits Its Codex Harness Docs Into Four Pages and Finally Explains How Memory Files Should Be Maintained

Two documentation overhauls landed on the same day. The Codex harness guide — a single page that tried to cover everything from quickstart to runtime internals — is now four focused documents. Separately, the memory system docs now spell out what belongs in your bootstrap file versus daily logs, and what happens when you ignore the distinction.

May 11, 20265 min read

Codex Harness — One Page Becomes Four

Codex Harness (Topic)

Setup-focused guide with quickstart and minimum viable configuration

Codex Harness Reference

Detailed configuration options, schema defaults, and parameter documentation

Codex Harness Runtime

Runtime behavior, version support contracts, and execution lifecycle

Codex Native Plugins

App configuration, dynamic tool timeouts, and workspace directory defaults

The Codex Harness Guide Was Doing Too Much

OpenClaw's Codex harness — the integration layer that lets the platform run OpenAI's Codex runtime as a managed agent — has been one of the most actively developed features in the project this year. But its documentation hadn't kept pace with that growth. Setup instructions, configuration reference, runtime behavior contracts, and native plugin details all lived on a single page.

The result was a document that new operators scrolled past to find the quickstart, and experienced operators scrolled past again to find the config key they actually needed. Neither group was well served.

That single page is now four. The topic page stays focused on setup: quickstart, minimum viable configuration covering OpenClaw config, CLI auth, model/provider selection, and plugin setup. Everything else moves into dedicated reference pages.

The runtime page documents version support contracts and execution lifecycle behavior. The reference page covers every configuration parameter with its schema defaults. And a new native plugins page documents app configurations, dynamic tool timeout precedence, and workspace directory defaults — details that were previously either buried in the main guide or only discoverable by reading the source code.

The navigation now groups the three reference pages under a dedicated “Codex harness” section in the Reference tab, while the topic page stays in Tools & Plugins where operators look for it first.

Cross-references throughout the rest of the documentation were updated to point to the correct new pages. The agent runtimes guide, for example, now links to the runtime page for version support details instead of sending readers to a specific anchor on the old monolithic page. The gateway configuration reference directs to the new dedicated reference page rather than the setup guide.

It's the kind of restructuring that doesn't change what the platform can do, but meaningfully changes how quickly an operator can find the answer they need.

Memory Docs Now Explain the Two-Tier System

OpenClaw agents have a two-tier memory system. There's MEMORY.md — a file loaded into every session's context at startup — and there are daily memory files stored in memory/YYYY-MM-DD.md that agents can search on demand. The distinction matters because only the bootstrap file counts against the prompt budget. Daily files don't.

Until now, the documentation described both surfaces but never explicitly told operators how to maintain them. The result was predictable: operators dumped everything into MEMORY.md because it was the file they knew about. Bootstrap files grew. Prompt budgets shrank. And when OpenClaw truncated the injected copy to fit the context window, operators saw degraded recall with no clear explanation.

The updated documentation adds a “What goes where” section that draws a clear line. MEMORY.md is for durable facts, preferences, standing decisions, and short summaries. It's described as “the compact, curated layer.” Daily files are for detailed session notes, raw observations, and working context — “the working layer” that search and retrieval tools index but that never gets injected into every prompt.

Agents are expected to periodically distill useful material from daily notes into MEMORY.md and prune stale entries. Heartbeat flows handle this automatically, but operators can trigger it manually.

The docs now also clarify a point that caused real confusion: truncation is not data loss. When the bootstrap file exceeds its budget, OpenClaw truncates the injected copy — the version the model sees. The file on disk is untouched. But repeated truncation warnings are a signal that the file needs curating. The recommended response is to condense summaries and move detail into daily memory files where search can still retrieve it.

Three documentation pages were updated: the memory concepts guide, the agent workspace reference, and the system prompt documentation. The system prompt page gained additional guidance that MEMORY.md should remain “a curated long-term summary” with detailed notes belonging in daily files. Operators can monitor their prompt-budget usage with /context list, /context detail, and openclaw doctor to stay ahead of truncation.

Memory Documentation Updates

Memory Concepts

New "What goes where" section distinguishing MEMORY.md from daily memory files

Agent Workspace

Expanded MEMORY.md description to reference daily log storage pattern

System Prompt

Added truncation guidance and curated summary expectations

Why It Matters

Neither of these changes adds a feature. Neither ships a fix for a runtime bug. But both address the kind of friction that compounds silently. An operator who can't find the config key they need spends twenty minutes reading source code. An operator who doesn't understand the memory model stuffs everything into one file and then debugs context truncation for an afternoon.

OpenClaw has grown fast. Its documentation has not always kept up. These two changes suggest the project is starting to treat documentation architecture with the same rigor it applies to code architecture — splitting monoliths, clarifying contracts, and writing the guidance that operators actually need instead of the guidance that was convenient to write.

Good docs don't just describe the system. They prevent the support tickets, the Stack Overflow questions, and the afternoons lost to assumptions that turned out to be wrong. OpenClaw shipped two of those today.

DeployClaw News · Analysis by Carlos Simpson

DeployClaw hosts OpenClaw instances. Upstream fixes ship automatically. This publication covers development independently.