ThisCodex

A reproducible setup for running Claude Code + Codex CLI multi-agent bots over Discord, wired into an Obsidian vault with shared folder/memory rules.

Role boundary: ThisCodex is the Codex-side bot-harness operations bundle. The general-purpose knowledge product is knowledge-manager; plugin installs go through tofukyung-plugins.

🇰🇷 한국어 README · 📘 Setup · 🌱 Beginner setup · ✅ Bot checkup checklist (KR) — 7-item self-checkup that your bot behaves as written (monthly) · 📦 Companion runtime: ThisCode (Claude Code side) · 📖 Getting started guide (English PDF, beginner, 14p) · This repo = the Codex side + cross-runtime conventions.

Install With Your AI Assistant

Copy this into Claude Code or Codex:

Follow the install files in https://github.com/treylom/ThisCodex step by step. Start from README.md and run the guided `npx github:treylom/ThisCodex init` setup (interactive, no flags). Ask Automatic or Manual as the first choice. In Automatic mode, actually try each recoverable step and record its result before asking me to do it; keep the same browser provider until completion, a named security gate, or a logged tool failure. Ask me before credentials, security approvals, or system changes. Finish with `npx github:treylom/ThisCodex doctor` or the documented verification commands.

New here? This one picture is the whole idea: a structured Obsidian vault, the right bot in each working directory (Claude Code and Codex), all driven from Discord, with the bots collaborating. ThisCodex is the Codex side — install it as a skill (skills/thiscodex/) and follow §3.

Before you start (recommended): lay out your Obsidian folder structure first and install Obsidian for full memory + internal-search. Without Obsidian you can still wire a plain Discord bot, but memory / internal-search quality is not guaranteed.

ThisCodex packages the hard-won, verified pattern for making a Codex CLI agent (codex by OpenAI) behave like the Claude Code Discord bots — same persona discipline, same Discord I/O, same vault rules — plus the multi-agent conventions (cross-bot addressing, meeting threads, SessionStart context injection) that let Claude Code and Codex agents collaborate in one Discord workspace.

It is not a framework. It is a documented set of building blocks you assemble yourself, with every claim traced to a source.

---

Codex plugin packaging

This repository now carries a canonical Codex plugin package surface: .codex-plugin/plugin.json, root skills/SKILL.md, plugin-level agents/, plugin.lock.json, and scripts/sync-to-codex-plugin.sh. The layout follows the current OpenAI plugin conventions seen in openai/plugins and the public obra/superpowers sync pattern.

Plugin packaging makes ThisCodex discoverable as a Codex plugin. Guided onboarding is still separate. After the plugin or skill is visible, run thiscodex init to confirm the repo, workspace, BOT_WD, state directory, Codex config, runner guidance, and final doctor checks before claiming the bot is ready. The first onboarding choice is Automatic versus Manual; it is separate from placement versus guided setup.

---

Help & Getting Started

First time? Ask Codex to "run the help skill" for the full skill map and stuck-point diagnosis, or start with:

"run the help skill"                                    # (Codex chat) full skill map + stuck-point diagnosis
npx github:treylom/ThisCodex init                       # (terminal) guided install
npx github:treylom/ThisCodex doctor --non-interactive   # (terminal) verification report — no questions, results only

Skill reference:

/name in this table is skill-name notation — it is not a slash command you type into Codex (Codex CLI v0.145 has no user-defined slash command surface). Ask Codex to "run the «name» skill" instead.

Skill	Purpose	Key subcommands
/thiscodex	Set up Codex as a Discord bot with Claude Code persona/rules	init, doctor, run, logs, features, troubleshoot
/create-bot	Create the Discord application through a connected browser-automation MCP	Developer Portal, intents, secret-safe token receipt, invite
/slack-bridge	Connect a Slack bot to local engines (Claude Code claude -p / Codex CLI codex exec) with Slack Bolt (Python)	Slack CLI auth, app + manifest, engine routing (codex: prefix), thread resume, meeting mode, one bot per engine
/prompt	Generate structured prompts for LLMs, GPTs, Gems, or image generation	<task description>, review:, gpt:, gem:, image:, research:
/setup	Step-by-step onboarding and verification	init, status, doctor, hooks, aliases, guide
/test	Run ThisCodex smoke tests (memory, tmux, meetings, rules, hooks, installer)	<feature name>, all

/slack-bridge answers anyone who posts in a public channel the bot has been invited to — any person and, until you add the stage-8 branch, any other bot too. Invite it only where everyone may run your local engines. It also behaves differently from ThisCode's Slack bridge (claude/channel: DM replies top-level, opt-in * channel wildcard, automatic receipt-emoji/✅ reactions, heartbeat); the comparison table sits at the top of its SKILL.md.

For each skill, load its detailed SKILL.md file for complete options and usage examples. All skills follow progressive disclosure — start with the summary, load detailed references only when you need them.

---

1. What you get

Capability	Status	Mechanism
Codex CLI as a persistent Discord bot	✅ working	codex app-server (headless) + Python bridge daemon (bot.py) + discord.py
Multi-client same-thread (watch/steer the bot's conversation from a TUI)	✅ working	codex resume <thread-id> --remote ws://… against the same app-server
Persona / vault rules auto-loaded	✅ working	canonical BOT_WD/AGENTS.md; SOUL.md is configured only as a legacy fallback when AGENTS.md is absent
Cross-bot addressing + meeting discipline	✅ working	bot-roster.yaml SoT injected at SessionStart
YOLO (full-access) execution	✅ working	thread/start and thread/resume both send sandbox:"danger-full-access", approvalPolicy:"never"
Image generation	✅ working	codex built-in image_gen.imagegen tool
Web fetch/search	✅ working	codex built-in web.run tool
Discord message reactions	✅ working	Call the exposed mcp__discord__react(chat_id, message_id, emoji) tool. Unicode emoji work directly; custom emoji use <:name:id>.
Discord thread history	✅ working	Call mcp__discord__fetch_messages(channel=<thread_id>). The thread's parent channel must be allowlisted, and the bot still needs Discord view/history permission.
Discord thread creation	✅ ThisCodex CLI	Creating public and private threads is an official Discord feature; enable CREATE_PUBLIC_THREADS (「공개 스레드 만들기」) and CREATE_PRIVATE_THREADS (「비공개 스레드 만들기」) in the server/bot permissions. ThisCodex calls the official Discord REST API directly. Only the matching command is absent from the currently shipped official Discord MCP, so ThisCodex exposes it through a reviewed dry-run-first CLI: thiscodex discord-thread public --channel-id <id> --channel-type <0|5> --message-id <id> --name "공개 스레드" or thiscodex discord-thread private --channel-id <id> --channel-type 0 --name "비공개 스레드"; inspect the plan, then repeat with . is an operator-declared value, not a lookup: verify the Discord channel object's (0=text, 5=announcement) before applying; Discord decides any mismatch. Private mode defaults to ; add only when members may add others. remains a reply reference, not creation.

Everything marked ✅ is empirically verified (see §6 Evidence). Everything ⏸️ is documented honestly with the upstream issue, not worked around.

---

2. Architecture

tmux session "sshee"
├── window: infra
│     codex app-server --listen ws://127.0.0.1:4222   (headless LLM runtime)
│        ▲ │  JSON-RPC over WebSocket
│        │ ▼
│     bot.py  ── discord.py on_message ──► Discord
│        - thread/start  (sandbox=danger-full-access, approvalPolicy=never)
│        - thread/resume (.codex-thread-id → SAME params re-applied)  ← critical
│        - per-turn: <channel chat_id message_id …> + "→ reply"
│        - codex calls mcp__discord__reply → Discord plugin REST POST
│
└── window: codex
      codex resume "$(cat .codex-thread-id)" --remote ws://127.0.0.1:4222
      → operator watches & can join the SAME conversation thread

Claude Code bots use the same shape, except the inbound-event injection is built into claude itself; for Codex a ~small Python bridge does turn/start. Outbound is identical (both call the mcp__discord__reply tool).

Key protocol facts (codex app-server JSON-RPC v2)

• Handshake: initialize → initialized → thread/start (or thread/resume) → turn/start → notification stream.
• Server-initiated requests the client must answer: mcpServer/elicitation/request (respond {"action":"accept","_meta":{"persist":"session"}} to allow the discord MCP), item/*/requestApproval, item/tool/call, item/tool/requestUserInput. Ignoring them hangs the turn forever.
• thread/resume loads from the on-disk rollout (~/.codex/sessions/YYYY/MM/DD/rollout-*-<tid>.jsonl); it accepts sandbox + approvalPolicy — you must re-send them or the resumed thread silently falls back to workspaceWrite / networkAccess:false (this was the single nastiest bug; see §6).

---

3. Setup

3.1 Prerequisites

• codex CLI (OpenAI), tmux, Python 3 with the bridge deps discord.py + websockets (python3 -m pip install -r requirements.txt — on Ubuntu 24.04+/PEP 668 add --break-system-packages, or install into a uv venv and set THISCODEX_PYTHON=.venv/bin/python before run.sh; the launcher runs that interpreter, shell venv activation does not reach tmux windows), the Claude Code Discord plugin (reused as a codex MCP server).
• Platforms: macOS / Linux / WSL2 (Ubuntu 22.04+). Native Windows → use WSL. computer_use is macOS-Apple-Events-bound and N/A on WSL/Linux regardless of upstream.

3.1a Node installer

ThisCodex ships a shell-zero Node installer. The default is interactive guided onboarding — run it with no flags:

npx github:treylom/ThisCodex init

Guided init first asks Automatic (auto) or Manual (manual), then walks you through repo root, workspace, BOT_WD, state dir, Codex config, superpowers availability, runner guidance, and the final doctor checks, asking one question at a time with safe defaults, then performs the writes only after you confirm. This is the path for both humans and AI agents handed the repo: an agent must run guided init and relay each question to the user — it must not auto-run a non-interactive install or report "copied = installed".

Automatic mode is enforced by install/automation-policy.yaml, consumed by the installer's strict YAML subset reader. Before an AI agent displays a manual fallback, it must call thiscodex automation-gate. Unlisted gates fail closed; attempt-required gates consume a completion envelope independently written by the app-server bridge for the current turn, while named credential, CAPTCHA, consent, and ownership boundaries require human_required. The returned short-lived receipt is required by both the Discord PreToolUse hook and the bridge fallback relay. Audits contain policy labels and evidence coordinates, never tool arguments/results, page text, URLs, or raw errors, and live at ~/.config/thiscodex/automation-attempts.jsonl (mode 0600). For browser work, the selected policy-listed playwright or claude-in-chrome provider stays attached until completion, a policy-declared human security gate, or a logged provider/tool failure. Starting a tool and switching to instructions is not completion.

--apply copies the thiscodex skill into a Codex-visible layer (~/.agents/skills/thiscodex by default), optionally backs up and patches ~/.codex/config.toml, and prints OS-specific runner instructions. It does not auto-start a daemon in scope A. ThisCodex install is manifest-driven (install/thiscodex.install.json); thiscodex doctor replays the same verify checks, so install success and diagnosis use one path.

Skill placement and guided onboarding are separate paths. Copying SKILL.md into a Codex skill layer only makes the skill visible; it is not completed onboarding. Guided onboarding confirms the repo, workspace, BOT_WD, state dir, Codex config, superpowers, runner guidance, and final doctor checks before claiming the bot is ready.

CI / automation (non-interactive opt-out)

Non-interactive mode is only for CI or diagnosis, and must be requested with an explicit flag:

npx github:treylom/ThisCodex init --non-interactive
npx github:treylom/ThisCodex init --apply --yes --answers <answers.json>

--non-interactive is a CI or diagnostic mode, not guided onboarding. It never invents missing paths. If a required decision is missing it stops — with an interactive-recovery hint when input is possible, or a clear Next command when not — instead of silently continuing or self-answering.

On Windows, use WSL first. If tmux is missing, ThisCodex uses a tmux one-command safety line: it explains why tmux is needed and offers one install command; it runs that command only if you explicitly consent. Aliases are generated only after confirmed_repo_root, confirmed_bot_wd, and confirmed_state_dir are known, so no temporary path is baked into your shell.

When running inside WSL, Windows skill sync is a first-class guided step. The installer detects /mnt/c/Users/*, asks which Windows profile to use, syncs only the thiscodex skill to %USERPROFILE%\.agents\skills\thiscodex, preserves other Windows skills, and verifies SKILL.md after the copy.

Superpowers must be available before the /using-superpowers interview step. If the Codex superpowers bundle is missing, the installer stops and prints a superpowers Next command; it does not pretend the guided interview happened.

Installer ownership

The Node installer is the single owner of Codex skill placement. It copies skills/thiscodex into the selected Codex-visible layer (~/.agents/skills by default, repo-local .agents/skills when selected). ThisCodex intentionally does not ship a second shell sync script; duplicate sync paths drift and are harder to run on Windows.

scripts/launch.sh remains a legacy/tmux fallback for operators who already run a bridge manually. New users should follow the Node runner guide. When launch.sh is used, set THISCODEX_SHELL=${SHELL:-/bin/sh} (or an explicit shell path) so the script does not require zsh.

When a user explicitly chooses YOLO/full-access mode, warn that the bridge's per-turn sandbox:"danger-full-access" and approvalPolicy:"never" can still be clamped by Codex app-server defaults unless ~/.codex/config.toml also has sandbox_mode = "danger-full-access" and approval_policy = "never". The installer may add those two keys only in the Q6e YOLO opt-in path, after showing the security warning and backing up the file. Safe mode remains the zero-config default.

3.2 ~/.codex/config.toml

# AGENTS.md is Codex's canonical filename; SOUL.md is legacy fallback only.
project_doc_fallback_filenames = ["SOUL.md"]
project_doc_max_bytes = 65536

[mcp_servers.discord]
command = "bun"
args = ["run", "--cwd", "<path to discord plugin>", "start"]
[mcp_servers.discord.env]
DISCORD_STATE_DIR = "~/.claude/channels/discord-<botname>"

3.3 Bot working directory

Put one canonical AGENTS.md in the bot WD. It contains the SOUL v2 persona capsule and the static Discord-reply rule (see §4), and points to the rules router. Codex selects one instruction file per directory; a same-directory SOUL.md is not loaded alongside AGENTS.md. SOUL.md remains a legacy fallback only when AGENTS.md is absent. Do not re-inject static persona text per turn.

3.4 Run it (the bridge is what grants access)

A 2-window tmux launcher (scripts/launch.sh): window infra runs your LAUNCH_CMD (codex app-server + the bridge daemon); window codex attaches an interactive TUI to the same app-server for live observation/steering.

Once the daemon runner is accepted, guided init treats the one-word launcher block as a default-yes recommendation; only an explicit no skips it. After the repository and bot working directory are confirmed, the printed aliases call the materialized <BOT_WD>/run.sh: thiscodex-start (and the compatibility name thiscodex-discord) removes only the exact same-named tmux session before restarting it, thiscodex-stop stops that exact session, and thiscodex-attach / thiscodex-tui reconnect to it. Paste the reviewed block into your shell rc if you want it permanent; the installer never edits the rc file automatically and never substitutes a developer-machine path. Guided init also asks for a short runtime name; that one value becomes the exact tmux session, BOT_NAME, and one-word launcher alias (for example pt). Do not invoke an alias on the same parsed line that defines or sources the rc block: the shell may parse the invocation before the alias exists, so open a new terminal or source the block on a separate line first.

launch.sh only supervises — the bridge daemon is what actually sends the sandbox. The reference bridge ships in this repo: examples/bot.py, and the rules it must obey are the YOLO bridge contract. Key points:

• Safe by default, YOLO opt-in, per-bot selectable. The bridge runs sandbox:"workspace-write" + approvalPolicy:"on-request" unless a bot opts in via env THISCODEX_YOLO=1 or an operator-controlled sentinel (THISCODEX_YOLO_FILE, default ~/.claude/channels/discord-<BOT_NAME>/.thiscodex-yolo — per-bot, and outside the model's writable dir so a model can't self-upgrade safe→YOLO), which switches that bot to sandbox:"danger-full-access" + approvalPolicy:"never". Unrestricted host access is a conscious per-bot choice, never the zero-config behavior — read the contract's Security section before enabling it.
• thread/start AND thread/resume re-send the same sandbox/approval. Omitting it on resume = silent fallback to the safe default after the first restart (§6). The contract makes this non-optional.
• Bridge auto-accepts the discord MCP elicitation with persist:"session".
• A bridge-level progress heartbeat prevents silent gaps on long turns (see the contract's heartbeat section + the soul/AGENTS proactive-report rule).

3.5 GitHub auth & superpowers

• GitHub: gh auth login (or a PAT in the environment) before launch so codex exec can push/PR.
• Superpowers / skills: codex reads AGENTS.md; point it at your skills directory and the migration rules (§5) so skill invocations resolve.

3.6 Codex hooks — plugin registration, human trust, aggregate verification

Version 1.1.0 ships one plugin-owned hooks/hooks.json. Once ThisCodex is installed and enabled in /plugins, Codex discovers the bundle in a new session; do not merge its handlers into ~/.codex/hooks.json by hand. Every bundled command first passes through hooks/lib/bot-only.sh, so a normal Codex session without DISCORD_STATE_DIR runs no bot target, writes no stdout, and exits 0.

The required set is exactly 12 handlers:

• SessionStart: bot-session-init.sh.
• UserPromptSubmit: rule-router.sh.
• PreToolUse: dispatch-room-gate.py, automation-handoff-gate.py, discord-readability-gate.py, automation-no-interactive.sh, and verify-before-push.sh.
• Stop: meeting-stop-reread.sh, reply-gate.sh, completion-gate.sh, dispatch-verify.sh, and kst-timestamp.sh.

meeting-liveness.py remains a standalone operator tool and is not part of the automatic bundle. The dispatch-room probe still applies to multi-bot installs: python3 hooks/dispatch-room-gate.py --probe must report PROBE PASS 6/6.

Registration is not activation. Codex skips a hook until a person reviews its current definition in /hooks; that approval records a definition hash in ~/.codex/config.toml. Use this sequence:

1. Run: thiscodex hooks --apply
2. Install/enable ThisCodex in /plugins and start a new Codex session.
3. Run /hooks, inspect all 12 ThisCodex definitions, and trust them.
4. Run: thiscodex hooks --verify

The verifier returns 0 only when the exact bundle, common guard, enabled plugin, all current trust hashes, and zero legacy conflicts are observed. Before trust, the honest state is registered_pending_trust; only a passing verifier is active. thiscodex doctor delegates to this same aggregate contract instead of checking one representative hook.

Migration proves ownership before deletion. thiscodex hooks --apply backs up and atomically removes an old JSON entry only when its basename is in the required 12 and at least one ownership signal is present: the bot-session wrapper, a case-insensitive thiscodex path segment, a sibling plugin manifest named thiscodex, or a missing target file. A path containing an unresolved $ variable never uses the missing-file signal; a copied current hook hash is not ownership proof. An unknown same-name JSON or inline config.toml entry is preserved and printed as a warning, but is not counted as a verification failure. A proven ThisCodex inline entry is also preserved, but remains a conflict that exits 1 and asks for one human /hooks review action. A second clean apply makes no file, timestamp, or backup change.

For isolated verification, run:

node --test tests/init/plugin-hooks-json.test.mjs tests/init/hooks-install.test.mjs
bash hooks/tests/run-hook-tests.sh

---

3.7 Troubleshooting — bot logs in but never replies

Five distinct causes share this one symptom (all field-measured 2026-08-09, WSL). First split the symptom in half with the ack reaction: no 🔍 on your message = the bot never heard you (most often you mentioned the role <@&…> instead of the user — Discord autocreates a same-named role on invite); 🔍 but no answer = the outbound side below. Check in order — the bridge log (run.sh window infra) now warns on each:

Check	What broke	Fix
~/.codex/config.toml has [mcp_servers.discord]?	codex has no reply tool at all (fresh machines)	add the §3.2 block
That entry's DISCORD_STATE_DIR = this bot?	replies go out as another bot, or die on its token	generated infra-launch.sh now pins it via -c; align config.toml for manual runs
.env line endings LF? (Windows paste = CRLF)	bot.py logs in fine, the discord MCP dies with "DISCORD_BOT_TOKEN required"	sed -i 's/\r$//' <state dir>/.env
BOT_WD/AGENTS.md exists (§3.3)?	model writes answers but calls no tool — mute bot, zero errors	init --apply now materializes it; keep the Discord Reply Rule section
<state dir>/access.json exists with your channel?	the MCP starts but refuses every send (reply failed: … not allowlisted) — the bot hears, never answers; the bridge now surfaces the refusal in-channel	copy the seeded access.json.example, fill in your channel/user ids, restart

Existence is not behavior: after fixing, prove it with one actual round trip sent after the fix (a reply that predates the fix proves nothing).

4. The multi-agent conventions (why this is more than one bot)

These are the rules that make Claude Code + Codex agents coexist. They live in bot-roster.yaml (single source of truth, injected at SessionStart):

• Cross-bot addressing: in shared channels, a message aimed at another bot must use its <@user_id> mention or a reply_to. Otherwise the receiving bot silently drops it. Bot user_ids are derived deterministically from the bot token's first base64 segment — never guessed.
• Direct channels are exempt from the mention rule (require_mention: false).
• Meetings = dedicated threads: any task with ≥2 bots, ≥10 min, or an agenda (2-of-3) gets its own thread; the main channel only gets a redirect. One-shot relays/ACKs stay inline.
• SessionStart injection: a single renderer (roster-inject.py) feeds the same coordinates + rules into both Claude Code bots (via the session-init hook) and Codex bots (via the plugin-owned hooks/hooks.json).
• Discord-reply rule (static, in AGENTS.md — not per turn): each turn arrives as <channel chat_id="…" message_id="…" …>; reply with mcp__discord__reply(chat_id, reply_to=message_id). Persona/vault discipline is always on because the canonical AGENTS.md is auto-loaded.

---

5. Claude Code ↔ Codex migration rules

Bringing a Claude Code agent's behavior to Codex (and back):

Concern	Claude Code	Codex equivalent
Persona/rules load	CLAUDE.md + SessionStart hook	canonical AGENTS.md; SOUL.md only as a legacy fallback when AGENTS.md is absent
Inbound Discord event	built into claude --channels	bot.py bridge → turn/start
Outbound	mcp__discord__reply tool	identical (discord plugin as codex MCP)
Tool approvals	permission modes	approvalPolicy + bridge auto-accept elicitation
Skills	Skill tool	AGENTS.md-declared skill dir; invoke via shell/exec until first-class
Persistence	session memory	thread/resume from rollout + .codex-thread-id
Sandbox	permission prompts	sandbox enum; re-send on resume

Rule of thumb: state that's dynamic per message stays in the bridge prompt; everything static moves to AGENTS.md (it is auto-loaded, so per-turn re-injection is pure noise).

---

6. Evidence (every ✅ is traced)

• Codex bot equivalence + 9 debug cycles: ThisCode / vault meeting 2026-05-15-codex-discord-bot-poc.
• Multi-client same-thread: verified by attaching a 2nd WS client and reading the bridge's live history.
• computer_use/browser_use: flag stable,true in codex features list but no official codex command/subcommand exposes it → not a callable tool. Triangulated: features list (flags true) vs GitHub #20851 (Desktop-app-bundled MCP only) vs clean app-server×dangerFullAccess turn → tool list = web.run, exec_command, image_gen, … (no browser/computer tool). 6 converging signals, confound-free.
• resume-sandbox bug: thread/resume without re-sending sandbox → effective workspaceWrite/networkAccess:false; fixed by re-sending the sandbox → verified {"type":"dangerFullAccess"}. Codified as a non-optional clause in the YOLO bridge contract and implemented in examples/bot.py.

---

7. Security note (read before enabling computer-use when #20851 lands)

When upstream exposes computer_use to the CLI, do not pipe untrusted Discord text into it via an LLM-enforced "treat as data" instruction — that has zero enforcement. Required: code-level default-deny, URL allowlist (block file:/javascript:/RFC-1918/metadata IPs), ephemeral browser profile, block sensitive-field type/click, full audit log of allow/deny, nonce/expiry/HMAC on any delegation. (Source: GPT-5.5 adversarial review, 2026-05-16.)

---

8. Status

• ✅ Codex Discord bot, multi-client, roster/SessionStart, safe/YOLO sandbox, image_gen/web.run/exec — working & verified.
• ✅ Reference bridge shipped — examples/bot.py + the runnable YOLO bridge contract (safe-default vs opt-in YOLO, resume-sandbox re-send, progress heartbeat). A deployment no longer needs to hand-roll the access-granting bridge.
• ⏸️ computer_use/browser_use — parked on openai/codex#20851.
• 🔁 Skill portability (Codex using Claude Code skills) + WSL/Windows codex skill absorption — in progress (collaborative). Superpowers: install via its own upstream codex path, see docs/skill-portability.md §2.5.
• ✅ Progressive-disclosure rules system (no context bloat — situational rule routing) — convention shipped, see docs/rules-system.md.
• ✅ Reversible memory archival (scripts/memory_dreaming.py) — move-not-delete cleanup to out-of-WD cold storage, one-command checksum-verified restore; one tier-agnostic rubric across all tiers incl. the Codex memory tier (~/.codex/memories, env-configurable cold subdir); conservative (auto-archive gated, ambiguous → human review), criteria self-correct from restores; weekly-enforced. Plain-language: docs/memory-dreaming.md.
• ✅ Meeting watchdog (scripts/meeting_watchdog.py) — recommended on every meeting (invite one watchdog bot per meeting, start before the first dispatch). On meeting-thread creation, YAML-enforced ~5-min progress check (maintainer's vault runs ~3 min); self-terminates only when goal AND all tasks complete (models Claude Code /goal); fail-closed = never falsely terminate a live meeting. Pairs with docs/05-meeting-thread-protocol.md §2.3 + §5.

License: see repo. Use on machines you control, with trusted private Discord servers only.