remem：Codex と Claude Code のためのローカル記憶レイヤー
Coding agent を長く使っていると、困るのは「まったく何もできない」ことより、毎回新人のように同じ説明が必要になることだ。この repository の約束、前回なぜその構造にしたのか、消してはいけない test、deploy script の場所、review で既に捨てた案。AGENTS.md に書くのは有効だが、何でも足すと備忘録の山になる。Chat history だけに置くと、tool や session をまたいで安定して使いにくい。
今日見るのは majiayu000/remem。Local-first な coding-agent memory layer として作られている。Rust の single binary、local SQLite と SQLCipher、Claude Code、OpenAI Codex / Codex CLI、一部 Cursor scenario 向けの hooks、MCP tools、CLI、localhost REST API という構成だ。Project documentation を置き換えるものではなく、project decisions、bug-fix rationale、preferences、work patterns のように session 間で失われやすい engineering memory を、検索できて監査できる local store に置くことを狙っている。
GitHub repository API、repository page、README、中国語 README、Release page、Cargo.toml、LICENSE、default branch の Git history を 2026-08-10 時点で確認すると、majiayu000/remem は 23 stars、3 forks。主要言語は Rust、license は MIT。Repository created time は 2026-02-20 17:35:19 UTC、latest public push は 2026-08-10 09:45:05 UTC。Default branch main の現在の HEAD は 75021d3、commit time は 2026-08-10 09:20:02 UTC、message は feat(context): persist SessionStart bundle audits。最新 GitHub Release は v0.6.65、published time は 2026-08-10 09:54:37 UTC。Cargo.toml の crate version も 0.6.65 になっている。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | majiayu000/remem |
| 位置づけ | Codex / Claude Code の local-first project memory layer |
| Stars | 23 |
| Forks | 3 |
| 主要言語 | Rust |
| ライセンス | MIT |
| 作成日時 | 2026-02-20 17:35:19 UTC |
| Latest push | 2026-08-10 09:45:05 UTC |
| 現在の default branch commit | 75021d3、2026-08-10 09:20:02 UTC |
| 最新 GitHub Release | v0.6.65、2026-08-10 09:54:37 UTC |
| キーワード | Codex、Claude Code、MCP、hooks、SQLite、SQLCipher、local-first、agent memory |
補っているのは「session 間の engineering memory」
remem の README は最初から問題をはっきり書いている。新しい coding-agent session ごとに project を説明し直したくない。Agent が新しい session を始めるときに、repository に関係する decisions、bug context、preferences を持ってきて、空の context から再探索しないようにしたい。
これは通常の README.md や AGENTS.md を置き換える話ではない。Documentation は安定した rules に向いている。Deploy path、code style、触ってはいけない service などだ。remem が向くのは、作業中に生まれるが、毎回手で project document に書くほどではない情報だ。Flaky test の root cause、ある refactor を避けた理由、module convention の由来、maintainer preference の source と適用範囲などがその例になる。
入口も agent workflow に寄っている。Install 後、Codex CLI や Claude Code に SessionStart / Stop hooks と MCP registration を設定できる。Session 開始時には関連 memory を注入し、終了時には永続化する内容を summary にできる。remem search "last decision" のように CLI から直接検索することも、MCP / REST 経由で他の local tools から使うこともできる。
インストールは素朴
README の主な installation path は Homebrew だ。
brew install majiayu000/tap/remem
REMEM_INSTALL_BINARY="$(brew --prefix remem)/bin/remem" remem install --target codexHomebrew を使わない場合は、repository の install.sh を使い、その後で ~/.local/bin/remem install --target codex を実行する。remem install は Claude Code、Codex CLI、Cursor の config directory を検出できる。初回は --target codex、--target claude、--target all のように対象を明示するのが分かりやすい。
Codex CLI では、README によると ~/.remem/.key、encrypted ~/.remem/remem.db、~/.remem/config.toml、~/.codex/config.toml の MCP registration、~/.codex/hooks.json の SessionStart / Stop hooks を作成または更新する。この deployment model の良さは単純さだ。Hosted database も大きな service stack もなく、memory は基本的に手元の machine に残る。
監査できることが大きな軸
Memory tools は「覚えられる」ことを強調しがちだが、agent では「なぜこの memory が出てきたのか」のほうが重要になることがある。remem の README には provenance、citation、injection audit、current-memory contract といった言葉が繰り返し出てくる。古い content を prompt に戻すだけではなく、staleness、temporal / as-of truth、citation usage、injection audit state を見えるようにする方向だ。
これは実務的だ。Agent が path を一つ間違えるだけなら数分の無駄で済むかもしれない。しかし deploy constraint を間違えると production に影響する。監査可能な memory layer なら、少なくとも問い直せる。この suggestion はどの session から来たのか。古くないか。なぜ選ばれたのか。他にどの memory が落とされたのか。Memory system がそれを説明できないなら、見えない implicit prompt になってしまう。
最新の default branch commit も同じ方向に見える。feat(context): persist SessionStart bundle audits という message だ。公開 commit message と README から見る限り、SessionStart context bundle の selection、budget、degraded state、truncation、reason metadata を永続化しようとしている。一方で、memory title、body、rendered hook output は記録しないと説明している。つまり「どの context が注入されたか」を、本文を保存せずに検査可能な runtime record に寄せている。
Cursor support は分けて読む
remem は Cursor にも触れているが、README は境界をかなり細かく書いている。remem install --target cursor は macOS / Linux で MCP server を登録し、user-level の ~/.cursor/hooks.json と ~/.cursor/mcp.json を管理する。ただし Cursor v1 の install surface は Cursor hook entries をまだ登録しない。そのため automatic memory capture は有効にならず、SessionStart injection も support されない。
これはむしろ良い caveat だ。多くの tool は「platform supported」と言い切り、実際には半分しか動かないことがある。remem は Codex / Claude Code と Cursor の capability difference を表にしている。読者にとって安定した試用 path は、まず Codex CLI または Claude Code で doctor、search、SessionStart injection、Stop summarization を通すことだ。その後で Cursor の MCP-only use case を見るのが現実的だろう。
どんな人に向いているか
remem は agent を日常的な development partner として使っている人に向いている。同じ repository で Codex に maintenance task を繰り返し頼み、前回の incident investigation path、検証済み command、直接変更してはいけない directory、延期した dependency upgrade の理由を覚えさせたい場合。あるいは Claude Code と Codex を行き来しながら、別々の session summary ではなく、同じ project-level memory を共有したい場合だ。
Privacy と control を気にする team や個人にも合う。SQLite file、local key、optional local embeddings、MCP、REST は手元の machine にある。少なくとも、すべての session summary を remote service に預けるよりは境界を説明しやすい。ただし、秘密を気軽に保存してよいという意味ではない。Database、key file、backup、exported Markdown、logs、indexes はまとめて security model に入れる必要がある。
逆に、たまに agent に小さな file edit を頼むだけなら重い。AGENTS.md、issue description、通常の context で十分なことも多い。Memory layer の価値は long-term accumulation と cross-session recall から出る。その需要がないなら、hooks と persistent storage は複雑さになる。
注意したい境界
第一に、project はまだ小さい。23 stars、3 forks で、latest push と release は新しいが、community validation は限られている。最初は personal repository、internal tools、low-risk project で試し、production decision に直結させないほうがよい。
第二に、automatic capture は memory pollution を起こす。失敗した仮説、一時的な path、一度きりの command、途中の debug conclusion まで長期保存すると、次の agent が古い noise に引っ張られる。remem は search、why、doctor、audit の方向を持っているが、使う側にも cleaning、correction、expiration policy が必要だ。
第三に、hook modification は慎重に扱うべきだ。~/.codex/config.toml、~/.codex/hooks.json、~/.claude/settings.json を変更できる tool は、clean environment で doctor を走らせ、config backup を残してから使いたい。Memory system が agent startup path に近いほど、development infrastructure として管理する必要がある。
まとめ
majiayu000/remem が面白いのは、agent memory を「session end に summary を一つ書く」だけのものにしていないところだ。Hooks が capture と injection を担当し、MCP / CLI / REST が access surface になり、SQLite / SQLCipher が storage を持ち、audit が memory の出現理由を説明する。Local engineering memory runtime として設計されている。
昨日取り上げた Perseus Vault は、より general-purpose な local MCP memory store に見えた。remem は Codex と Claude Code の日常的な development session に近い場所から入っている。同じ project に何度も agent を呼ぶ programmer にとって、project background を説明し直す負担を下げつつ、local control と audit trail を残す方向として観察する価値がある。