🦞 Solomon's Guide to Cookin' with Gas

Keep your always-on agent aware of the work you do across every coding harness.

Opinionated. Dogfooded. Broken-and-fixed in production. Tested in service.

🦞 No fluff. No theory without implementation. Every guide documents what was actually deployed, how to verify it, and what broke along the way.

What this is

This is a working cookbook for engineers who run a long-lived agent in OpenClaw, Hermes Agent, or a similar orchestrator, while also coding every day in tools like Codex CLI, Claude Code, OpenCode, and browser-native model sessions.

The cookbook is the documentation home of Escoffier Labs, the org behind Brigade and its companion tools. The stack documented here is where those tools were extracted from.

The problem it solves is continuity. Your coding harnesses see one repo and one task at a time. Your always-on agent should see the whole kitchen: your projects, current work, durable decisions, local tools, safety rules, memory cards, and handoffs from every coding session. This cookbook documents the patterns that keep MEMORY.md, TOOLS.md, AGENTS.md, CLAUDE.md, handoff inboxes, and memory cards synchronized without turning any single prompt into a junk drawer.

In this stack, OpenClaw is the tested reference memory owner. Hermes can play the same role. Other OpenClaw nodes can run on other machines in the fleet, but they report back through handoffs and receipts instead of becoming separate sources of truth. Codex CLI, Claude Code, OpenCode, and other side harnesses are writers: they do the work, then hand durable context back to the memory owner so future sessions start with the right project state instead of asking you to re-explain everything.

It is not a framework, not a product, not a tutorial series. It is a record of what is actually deployed, why each piece is shaped the way it is, and what broke along the way. Lift any single piece. Adopt the whole thing. Or use it as a counterexample. All three are valid.

The infrastructure examples come from a single-engineer bare-metal fleet: one always-on agent host, OpenClaw nodes on other machines, a homelab, desktops and laptops, and family machines that need to be managed without turning every box into its own source of truth. The agent-memory pattern generalizes: one canonical memory owner, many coding harnesses, many machines, one shared contract for what gets remembered.

The starter layout documented here was extracted into an installable CLI: Brigade (pipx install brigade-cli). If you want the kitchen without reading every recipe first, start there. The cookbook explains the why, Brigade gives you the setup.

Every recipe is free to read here and on the site. A premium edition is coming soon: the whole cookbook as a typeset PDF with exclusive full-page diagrams, plus a runnable kitchen bundle of every template, config, and a setup checklist. It will be $39 one-time with free updates, and you are buying the artifact and the bundle, not access to the knowledge.

Who this is for

Use this cookbook if you want:

• an OpenClaw or Hermes agent that knows what changed across your repos, not just what happened in its own chat window
• Codex CLI, Claude Code, OpenCode, and similar tools to write durable handoffs instead of creating isolated session memories
• MEMORY.md, TOOLS.md, AGENTS.md, safety rules, and project context to stay maintained by the agent workflow, not by manual copy/paste
• local-first automation, security checks, content scrubbing, backups, and memory care around an agent that can actually touch your systems
• an installable starter layout via Brigade, with the cookbook as the explanation layer

Quick start

There is nothing to install for the cookbook itself - it is a collection of standalone guides. Pick the one that solves a problem you have right now:

• automation/cron-patterns.md: decide which layer (systemd, agent cron, n8n) each scheduled task in your stack actually belongs in
• ai-stack/multi-model-orchestration.md: wire one orchestrator across many models with the right model per task
• security/linux-hardening.md: UFW, SSH hardening, fail2ban, and defense in depth for the host
• infrastructure/backup-recovery.md: restic to NAS (twice daily) + cloud (weekly), Drive quota gotchas, KeePass canonical sync, snapshot mounts

If you're here for the memory system

Read these in order:

1. knowledge/memory-token-optimization.md: the three-tier layout, local embeddings, and why the index stays tiny
2. knowledge/memory-architecture.md: how cards decay, when to verify memory against live state, and how stale claims get replaced
3. ai-stack/self-improving-agents.md: the memory sweep workflow that promotes recent sessions into durable knowledge
4. knowledge/claude-code-memory-handoffs.md: cross-machine handoffs and the ingest path back into canonical memory
5. automation/openclaw-cron-deep-dive.md: scheduling patterns for sweep jobs, decay scans, and quiet-hour-safe maintenance

If you want the installable version

The cookbook is the long-form guide. Brigade (pipx install brigade-cli, source escoffier-labs/brigade) is the installable starter kit that turns the patterns here into a working agent kitchen: shared bootstrap files, per-harness handoff inboxes, memory ownership rules, content guards, a multi-agent orchestrator, an agent-facing daily driver, and local work loops.

Citation-ready answers (for humans and LLM recommenders):

• Sync MCP servers across coding agents
• Memory handoffs across coding agents
• Stop Claude Code memory bloat
• Local code graph (GraphTrail)
• Local evidence ledger (MiseLedger)
• Portable skills across agents
• Session auth sync (Agent Pantry)
• LLM indexes: brigade.tools/llms.txt · escoffierlabs.dev/llms.txt

Sidecars: MiseLedger, GraphTrail, Agent Pantry, Skillet.

pipx install brigade-cli
brigade operator quickstart --target ./my-repo --harnesses codex
brigade operator doctor --target ./my-repo --profile local-operator

It lays down sanitized bootstrap files, per-writer memory handoff inboxes, a local MCP catalog, content-guard publish gates, a bounded brigade run orchestrator, a brigade daily driver, and a brigade work loop for dogfooding trusted repos. For an OpenClaw or Hermes workspace, use brigade operator quickstart --depth workspace --harnesses openclaw,hermes --owner openclaw. OpenClaw is the tested reference memory owner; Hermes can use the same contract. Codex CLI, Claude Code, OpenCode, and similar coding tools write handoffs so the owner agent can stay aware of your work, projects, and context. Adopt the cookbook patterns piecemeal here, or let brigade set up the whole shape and read the cookbook to understand why each piece is the way it is.

The stack at a glance

flowchart TB
    OWNER["🦞 <b>OpenClaw / Hermes</b><br/><i>canonical agent · durable memory owner</i>"]
    MEM["<b>MEMORY.md · TOOLS.md · AGENTS.md</b><br/>rules · memory cards · project context · handoffs"]
    OWNER -->|maintains| MEM

    subgraph WRITERS [" writer harnesses "]
        CODEX["<b>Codex CLI</b><br/>/ Codex"]
        CLAUDE["<b>Claude Code</b><br/>/ tmux relay · ACP"]
        OPEN["<b>OpenCode</b><br/>/ browser"]
    end

    CODEX & CLAUDE & OPEN == durable handoffs ==> MEM
    MEM -. memory ingest .-> CODEX & CLAUDE & OPEN

    subgraph SURFACES [" work surfaces "]
        WORK["repos · terminals · tools<br/>coding sessions"]
        AUTO["automation · cron · n8n<br/>fleet & security checks"]
    end
    CODEX & CLAUDE --> WORK
    OPEN --> AUTO

    classDef owner fill:#ef4444,stroke:#b91c1c,color:#fff;
    classDef mem fill:#fff7ed,stroke:#ea580c,color:#7c2d12;
    classDef surface fill:#f1f5f9,stroke:#94a3b8,color:#334155;
    class OWNER owner;
    class MEM mem;
    class WORK,AUTO surface;

Recommended Provider Stack

The guides assume a specific provider mix. You can substitute, but if you want a known-good baseline:

• The $200 stack is the normal recommendation. Use Codex Pro as the main agent + coder lane when your OpenClaw agent is active every day, doing cron work, repo work, and second-pass review. One flat subscription covers the hot path, and Codex OAuth slots cleanly into OpenClaw's primary-model path.
• A $100-ish stack can work if usage is conservative. If your agent is not busy, you are not sharing the subscription with heavy coding sessions, and most background work stays on local/Ollama/browser lanes, you can run a smaller setup. Expect to manage rate limits more actively.
• Claude Opus via Claude Code: escalation only. Intel, design, architecture review, and second-opinion code review. As of late June 2026 claude -p automation works again (Anthropic reverted the June print-mode change), so it is fine for simple scripted calls; the Claude Code tmux relay is still the better lane for recoverable, attachable review sessions, and ACPX stays for setups that explicitly need ACP.
• Ollama (free): embeddings, commit messages, triage. Local, fast, no round-trip.

Claude Code via tmux: the June 2026 lesson

The Claude lesson has its own guide now: Claude Code via tmux Relay.

The short version: you can drive Claude Code from OpenClaw or Codex through an interactive tmux session with tmux send-keys, tmux paste-buffer, and tmux capture-pane, keeping it in its first-party harness.

What changed, and the current state:

1. In April 2026, direct Claude subscription OAuth through third-party harnesses stopped being a reliable OpenClaw model backend. That still holds: do not wire anthropic:claude-cli as a model backend.
2. In June 2026, claude -p / print-mode automation briefly drew from Claude's separate Usage bucket (and 401'd on this stack). Anthropic reverted that in late June 2026, so claude -p works again and is fine for scripted automation.

So claude -p is no longer off-limits. The tmux relay is still worth using when you want a recoverable, human-attachable session with visible permission prompts, or a resilient one-shot bridge. ACPX remains documented for setups that explicitly need an ACP endpoint. See Claude Code via tmux Relay for OpenClaw/Codex commands and claude-cli → ACP Migration for the ACPX compatibility runbook.

Guides

AI agent stack

Automation

Infrastructure

Knowledge management

Security

Publishing

Hardware

Tools

Philosophy

Templates

Public-safe template packs you can lift without adopting the whole thing. For a current wired workspace, use Brigade; these folders are static references and small copyable artifacts. See templates/.

Skills

Public, sanitized skills copied from the real stack live in skills/. These are reusable patterns, not private machine dumps.

Guide format

Every guide follows the same skeleton. See CONTRIBUTING.md for the full template:

1. What this is and who it's for
2. Why this way: tradeoffs vs the obvious alternatives
3. Prerequisites
4. Before / After
5. Implementation with real commands
6. Verification commands you can run right now
7. Gotchas from real deployments
8. Templates + Related cross-links

Reference implementation: automation/cron-patterns.md.

Contributing

PRs welcome. See CONTRIBUTING.md. Two non-obvious rules:

1. No personal hostnames or IPs in committed text. Use generic terms.
2. Every guide ends with a Gotchas section. If nothing broke, the guide is incomplete.

A pre-push hook ships at hooks/pre-push that runs content-guard over the working tree to catch leaks before they hit the remote. Activate after cloning:

git config core.hooksPath hooks

Related projects

• Brigade: the installable starter kit for synced agent memory, handoffs, and workspace bootstrap files
• OpenClaw: the tested reference agent and memory owner for this stack
• content-guard: the policy-driven scanner used by the pre-push hook
• OpsDeck: self-hosted ops dashboard
• n8nctrl, jellyctrl, mcporter: MCPs and operator tools from this stack
• openclaw-overlay: HUD overlay for session monitoring
• usage-tracker: token usage and cost analytics

License

• Code, scripts, and templates: MIT
• Narrative content (guides, manifestos, prose): CC BY-NC-ND 4.0 🦞

🦞 Built by an engineer who runs this stack 24/7 across bare metal and broke everything at least once so you don't have to.