AgentMemory 0.9.11 Shows the Agent Plugin Format War Is Really About Portable Authority

AgentMemory 0.9.11 looks, at first glance, like a small integration release: a Codex plugin manifest, a marketplace entry, and a fix for an OpenClaw memory-slot bug. That undersells it. The release is a useful snapshot of where coding-agent infrastructure is going: memory, hooks, skills, MCP servers, and host capability declarations are becoming portable units of authority.

That phrase matters. A plugin is not just a nicer install command. In agent runtimes, a plugin can change what the model sees before a turn, what gets captured after a turn, what tools appear through MCP, which lifecycle hooks run around tool use, and which skills the agent can invoke. If that bundle can now move from Claude Code-style packaging into Codex and OpenClaw with only host-specific adapters, the industry is no longer passing around dotfiles. It is passing around executable operating policy.

AgentMemory's release notes say version 0.9.11 was published on May 12 and adds plugin/.codex-plugin/plugin.json, plugin/hooks/hooks.codex.json, and a root .codex-plugin/marketplace.json. The Codex plugin installs AgentMemory as MCP plus lifecycle hooks plus skills. The release lists 51 MCP tools when AGENTMEMORY_TOOLS=all is used, six Codex lifecycle hooks, and four skills: /recall, /remember, /session-history, and /forget.

Portability is becoming a runtime contract, not a README badge

The Codex side is interesting because it is deliberately compatible with the existing Claude Code plugin shape. OpenAI's Codex plugin documentation describes plugins as bundles of skills, app integrations, and MCP servers that Codex can install and use through the app or CLI. AgentMemory's PR #311 goes one layer lower: it says Codex's hook engine injects PLUGIN_ROOT, PLUGIN_DATA, and Claude-compatible aliases such as CLAUDE_PLUGIN_ROOT and CLAUDE_PLUGIN_DATA into hook subprocesses. That means scripts written for the Claude Code plugin layout can often run under Codex without a rewrite.

That is good developer experience. It is also a security review problem wearing a hoodie. Compatibility lets useful tools travel faster, but it also lets assumptions travel. A hook script written for one host's permission model may now execute inside another host with different approval prompts, working directories, data roots, marketplace conventions, and environment variables. The same path reference resolving successfully is not the same thing as the same authority boundary holding.

AgentMemory handles part of this well by trimming the Codex hook set to what Codex actually supports. The release registers SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact, and Stop. It explicitly drops Claude-Code-only events including SubagentStart, SubagentStop, SessionEnd, Notification, TaskCompleted, and PostToolUseFailure. The review history is reassuringly mundane: an initial description implied 12 hooks, reviewers corrected it to six, and the test suite was tightened to assert PreCompact so the manifest cannot silently drift.

That is the right level of boring. Plugin manifests should be tested like code because they are code in all the ways operators care about. A bad manifest does not just fail an install; it can create a false picture of what hooks run, what tools are exposed, or what skills are available. In agent systems, false pictures become bad approvals.

The OpenClaw fix is small because the bug was architectural

The OpenClaw change in PR #310 is less flashy and probably more important for platform operators. AgentMemory already declared kind: "memory" in its OpenClaw plugin manifest and wired the expected before_agent_start and agent_end hooks. The memory server and REST API could work end to end. But OpenClaw 2026.4.9 and newer still reported plugins.slots.memory = "agentmemory" as unavailable because the plugin never called api.registerMemoryCapability(...).

That is exactly the kind of split-brain integration state that makes agent platforms painful. The thing works, except the host cannot see it. Or worse: the host thinks nothing is occupying a slot while a hook is still injecting context into the prompt. For humans, that is confusing. For policy systems, dashboards, and automated diagnostics, it is poison.

The fix is to call api.registerMemoryCapability({ promptBuilder }) when the host exposes it, guarded by typeof api.registerMemoryCapability === "function" so older OpenClaw builds continue to load through the hook-only path. The prompt builder emits a short memory disclosure block: AgentMemory is the long-term memory provider, recall happens before each turn, completed turns are captured after the turn, and recalled context should be treated as background rather than authoritative. That last sentence is not fluff. Memory is useful context, not a command channel. Saying that in the prompt is a small but healthy act of runtime honesty.

The release also avoids pretending AgentMemory is an in-process OpenClaw memory backend. The PR notes that OpenClaw's current memory runtime backend config is shaped around built-in or QMD-style backends, not an external REST memory service. So AgentMemory claims the capability that exists today and leaves a runtime adapter for a future upstream backend shape. That restraint is worth noticing. A lot of agent integrations get into trouble by faking host-native semantics because the demo looks cleaner.

Tests back the change: PR #310 reports 871 passing tests, PR #311 reports 874, and the release bump reports 877 passing tests with a clean build. Test counts are not a quality guarantee, but here they tell the useful story: the project is treating integration contracts as regressable surfaces, not screenshots.

What builders should do with this

If you are building agent plugins, the lesson is not "support Codex too." The lesson is to separate capability from convention. Hooks are powerful, but host-visible capability registration is what makes a platform honest. If your plugin injects memory, say so through the host's capability API. If your plugin exposes tools through MCP, make the manifest explicit and test every referenced path. If your plugin bundles skills, treat those instructions like code review material, not onboarding copy.

If you are operating agents, review portable plugins the way you review dependencies. Ask what lifecycle hooks run, what environment variables are injected, what MCP tools appear, what data directory the plugin writes to, what skills it loads into the model's context, and whether the host can actually observe the capability. The install command may be one line. The authority surface is not.

The broader trend is clear. AGENTS.md, CLAUDE.md, SKILL.md, Codex plugins, MCP configs, hooks, and OpenClaw slots are converging into a layered package format for agent behavior. That is better than every host inventing a bespoke pile of instructions. It also means agent configuration is becoming a supply-chain artifact. The package can remember things, alter prompts, call tools, run scripts around tool execution, and present itself in marketplaces. That deserves provenance, tests, version pins, and an approval model more serious than "seems useful."

AgentMemory 0.9.11 is not a huge release by diff size. It is useful because it shows the market's center of gravity moving from local memory helper to portable agent infrastructure. The winning agent plugin format probably will not be one markdown file. It will be a manifest, skills, hooks, MCP definitions, host capability claims, and policy adapters. That is a real platform layer. Treat it like one.

Sources: AgentMemory v0.9.11 release, PR #311, PR #310, OpenAI Codex plugins documentation