Sekha

Sekha

**Persistent memory for Claude Code. Zero dependencies. Plain markdown. Plus: the only AI memory system that can hard-block destructive tool calls.**

What Sekha does

**1. Remembers things across sessions.** Tell Claude in one session, ask about it in the next, and it knows. Preferences, decisions, project context, anything — saved as plain markdown files under `~/.sekha/`. Close Claude Code. Open it again tomorrow. The memory is still there.

Claude invokes `sekha_save` / `sekha_search` / `sekha_list` / `sekha_delete` via MCP to manage the memory itself. You just talk to Claude normally.

**2. Blocks dangerous tool calls (the moat).** Sekha hooks into Claude Code's `PreToolUse` event and returns `permissionDecision: "deny"` when a tool-input matches a regex rule you've written. The AI **cannot bypass this**, even with `--dangerously-skip-permissions`. `rm -rf`, `git push --force`, `DROP TABLE` — whatever you choose to guard. Rules are plain markdown in `~/.sekha/rules/`, so your enforcement policy is as reviewable as any other config under version control.

Every other memory system (MemPalace, Mem0, Letta, Zep, Basic Memory, CLAUDE.md) only stores rules. Sekha enforces them at the hook boundary.

Honest scope

**What Sekha enforces (hard):** regex-matchable tool-input patterns -- `rm -rf /`, `git push --force origin main`, `DROP TABLE users`. The PreToolUse hook vetoes the tool call before it runs.

**What Sekha does NOT enforce:** behavioral rules like "always confirm before acting" or "no assumptions." Those remain prompt-level reminders and the AI can override them. See the [Threat Model](#threat-model) for why this is a fundamental limit of today's Claude Code hook surface, not a bug in Sekha.

Memory across sessions


*Claude remembers what you told it in a previous session — saved as a markdown file under `~/.sekha/`, retrieved via the `sekha_search` MCP tool on demand.*

Blocking a