Where Mneme fits in a Warp workflow
Warp's strength is execution: an engineer issues intent, Warp orchestrates the agents, processes, and tool invocations that fulfill it. Agent Mode pushes that further — autonomous loops that read, plan, edit, and verify across many shells in parallel.
That orchestration is upstream of any enforcement point. Mneme does not hook into Warp itself: governance reaches Warp-driven work only when the underlying agent carries a Mneme hook (Claude Code) or when mneme check gates the resulting diff in CI.
This is not a native Warp integration. Mneme does not have a Warp-specific hook. Governance reaches Warp-driven work only when the underlying agent carries a Mneme hook (Claude Code) or when mneme check gates the resulting diff in CI.
What gets enforced regardless of how Warp executes
- ADRs and architectural decisions. Recorded in
.mneme/project_memory.json, enforced whenever a governed surface touches them — an interactive Claude Code session inside a Warp pane, or a CI gate on the diff. - Forbidden dependencies and approved patterns. Catalogued as anti-patterns and constraints; surfaced as feedback when an agent attempts a violating edit.
- Path and boundary rules. Module-level constraints (e.g. "no direct database access from controllers") that hold regardless of which session produced the diff.
- The CI gate.
mneme checkruns against every PR diff in GitHub Actions or GitLab CI — the final line of defense after generation, independent of which terminal launched the work.
The seam: Warp orchestrates, Mneme governs
Warp Agent Mode coordinates parallel agents in dedicated panes. Each agent eventually writes to disk through a tool call. Mneme operates at that boundary:
- If the agent is Claude Code, the Mneme PreToolUse hook intercepts
EditandWritecalls before disk — violations exit 2 with the decision id, and Claude Code adjusts. - If the agent is Cursor running inside or alongside a Warp pane, the Mneme-generated
.cursor/rules/mneme.mdcfile is what the session reads as context. - If the agent is any other tool that writes to the repo, the CI gate catches the diff at PR time.
None of these paths require Warp itself to know about Mneme. The governance layer sits below the orchestration layer.
Setup
pip install mneme-hq
mneme init
# Wire Claude Code hook (if using Claude Code in Warp panes)
mneme hooks install
# Wire CI gate
mneme check --mode warn # try locally first
From there, every agent Warp runs inherits the same enforcement — no per-agent configuration, no Warp-side install.
If you use Warp Agent Mode with Claude Code
This is the most common combination today. Warp coordinates multiple Agent Mode panes, each running Claude Code against a slice of work. Mneme's PreToolUse hook applies in every pane simultaneously:
- Each Claude Code session reads the same
project_memory.json - Each
EditorWritetool call is intercepted before disk - Violations surface in the agent's own feedback loop — not as a post-hoc PR comment
- Parallel sessions cannot diverge architecturally because they all defer to the same corpus
Why this matters as agents scale horizontally. When Warp runs four Claude Code agents in parallel, the failure mode without governance is four mutually-inconsistent diffs that all "pass" because each agent only sees its own slice. Mneme makes the architectural corpus the shared invariant they all read against.
FAQ
Is this a native Warp integration?
mneme check gate in CI. There is no Warp-side install.Does Mneme slow down Warp Agent Mode?
What about Warp workflows that don't use Claude Code?
mneme check runs in GitHub Actions or GitLab CI against every PR diff regardless of which agent or tool produced it. For interactive enforcement with non-Claude agents, the Cursor Rules export or repo-level conventions are the available surfaces today.