thedotmack

Stars and mentions

Last 30 days, Oct 4 – Nov 2

GitHub stars12,176
mentions141
04599181.4K1.8KOct 4Oct 18Nov 2
UTC days · repositories thedotmack owns8 repositories

Package downloads

Cumulative recorded downloads · since 2025-10-21

npm580.4K
0145.1K290.2K435.3K580.4KOct 4Oct 18Nov 2
Oct 31npm: 1/2 packages observed

Across 2 known packages in repositories thedotmack owns. Cumulative totals include recorded downloads before the selected range. Missing observations leave gaps; totals may be incomplete.

Top repositories

thedotmack’s repositories ranked by new stars, as on trending.

Loading

Contributes to

Repositories outside thedotmack’s account where thedotmack opened or reviewed pull requests in the past 365 days.

Who noticed thedotmack

Everyone who starred or forked thedotmack’s repositories since the archive began in 2011.

Notable accounts

Ordered by the stars their own repositories have received.

Biggest fans

Accounts that starred the most of these repositories.

Breakout weeks

Each repository’s best week of new stars, with the release published around it.

Mentions

146posts
Nov 37 posts
  1. Claude-MemはSIerで安全に使える?仕組みとプロジェクト間のメモリ分離をコードから調査 はじめに zenn.dev 異なるコーディングエージェントの情報を共有できるclaude-memというライブラリがあるみたいです。 Claude-Memは、コーディングAgentの作業履歴を自動収集し、AIで圧縮して、次のセッションで使えるようにするOSSです。 便利そうですが、セキュリティリスクは検討しないといけません。 同じ開発者が顧客Aと顧客Bの案件を並行して担当していたとき、顧客Aの設計やコードの情報が顧客BのAIの回答に紛れ込まないでしょうか。 本記事では仕組みを整理したうえで、「PJごとに記憶が分類される」ことと「PJをまたいで情報を読めない」ことの違いを中心に、ソースコードと公式ドキュメントからPJの案件情報が混在しないかを確認します。 結論 通常のセッション開始時のコンテキスト注入は、デフォルトでは現在のプロジェクトを対象にする。 保存先はローカルWorker構成の場合、同じOSユーザーの ~/.claude-mem/ 配下のSQLiteなど。複数PJの記録が同じ保存基盤に入る。 PJ名による絞り込みはアクセス権限ではない。 ローカルMCPの検索操作では project を省略でき、検索が他PJのデータに及ぶ経路がある。明示的に別PJを指定する操作も、企業のテナント認可としては扱われない。 共有の制御は存在する。 名前付きEnvironmentの inherit、クラウド同期、TeamBrainなどがある。ただし、それぞれ「同一端末内の検索範囲」「同一アカウントの端末間同期」「チームへの選択的共有」と意味が異なる。 受託開発での推奨は、顧客単位の実行環境・保存領域・外部通信を分けること。 通常開発は管理された既存PCまたはWindows 365、高機密案件では案件専用Azure VMなどを候補にする。設定で current や inherit: [] を指定しただけでは、厳密な顧客間分離の保証にならない。 1. Claude-Memは何を記憶しているのか Claude-MemはClaude CodeなどのライフサイクルイベントをHookで受け取り、作業の途中で発生した情報を整理して保存する「外付けの永続メモリ」です。 処理を大きく分けると次のようになります。 UserPromptSubmitで指示を、PostToolUseなどでファイル操作・コマンド実行・結果を収集する。 Workerが要約モデルを使って「どんな問題を解き、何を決定し、何を変更したか」をObservationとして圧縮する。 観測結果、セッション要約、ユーザープロンプトをSQLiteに保存する。FTS5でキーワード検索でき、Chromaを使えば意味検索もできる。 次のセッション開始時や検索要求時に、必要な過去情報をAIのコンテキストへ戻す。 検索は、まず短い結果一覧を取得し(search)、前後の経緯をたどり(timeline)、必要な記録だけ詳細取得する(get_observations)という段階的な方式です。すべての履歴を毎回LLMへ詰め込まない設計になっています。 ここで重要なのは、LLMに渡す情報を小さくすることと、保存されるデータが少ないことは同義ではないという点です。要約された記憶とは別に、プロンプトや作業由来の情報もローカルに残ります。 2. 「PJごとのメモリ」はどこで分離されているか ローカルWorker構成を、同一OSユーザーが複数の案件を扱う状況で考えてみます。 PJ単位のラベルやフィルターはありますが、PJごとに自動で独立したDBが作成されるわけではありません。 現行のローカルWorkerは、同じユーザーデータ領域に複数PJの記憶を保持できます。 2-1. プロジェクト名をどう決めるか 基本の識別方式はフォルダやGitリポジトリに基づきます。現行実装には次のルールがあります。 開発環境 主な識別方法 SIerでの注意 通常のGitリポジトリ Gitルートフォルダ名(標準のpathモード) 顧客が違っても同じフォルダ名なら衝突しうる Gitのoriginあり git-remoteモードなら org/repo フォルダ移動に強いが、ホスト名までは識別子に入らない Git worktree 親PJとworktreeを関連付け、親の記憶も読める ブランチ単位の完全分離ではない Git submodule 親PJ配下の識別子を使い、親の記憶も参照 サブモジュール単体の閉域を意味しない Git管理外 カレントディレクトリ名、マーカーファイル等 フォルダ名の重複や移動に注意 名前付きEnvironment パスのglobパターンにより指定名へ割り当て 複数のフォルダを意図的に同じメモリへまとめられる たとえば、二つの顧客案件のリポジトリがどちらも backend というフォルダ名なら、標準の命名では識別名が重複するリスクがあります。git-remote を利用すれば軽減できますが、異なるGitホスト上の同一 org/repo が区別されないケースも設計上考慮が必要です。 2-2. デフォルトの自動注入は「現在のPJ」 CLAUDE_MEM_CONTEXT_PROJECTS の標準値は current です。通常の SessionStart では、現在のcheckoutに対応する履歴を読み込むよう設計されています。all にすると複数PJを対象にしたコンテキスト注入が可能です。 つまり、何も設定しなければ全PJの全履歴が毎回AIに注入される、という仕様ではありません。 ただしこれは「どの情報を注入するか」の既定動作であり、アクセス制御ではありません。 同様に、CLAUDE_MEM_SESSION_START_INCLUDE_ALL_SOURCES=false は、Claude Code・Codexなど複数のハーネスをまたぐ自動注入を制限する設定です。これもユーザーや顧客ごとの閲覧権限を実現するものではありません。 2-3. 意外に重要:検索ではPJスコープが省略できる ソースコード上、ローカルWorker向けのMCP search / get_observations などは project が任意引数です。検索側はPJ条件が渡された場合にSQLの絞り込みを組み立てますが、渡されない場合はそのPJ条件を付けません。 さらに withCheckoutProjects() は、現在のcheckout名が明示的に指定された場合には継承キーを補完しますが、スコープ指定がない検索を強制的に現在のcheckoutへ閉じる関数ではありません。 そのため、次の二つは分けて評価する必要があります。 セッション開始時に「顧客Aの記憶だけが自動表示される」こと 顧客Aの環境から「顧客Bの記憶を検索・取得できない」こと 前者はデフォルト動作として期待できますが、後者をローカルWorkerのPJフィルターだけで保証するのは危険です。 同じユーザープロセスに対する操作を悪用したメモリ汚染や、誤った検索指示による情報の混入も想定すべきです。 この問題はGitHub Issue #3764 でも指摘され、より広いPJ識別・検索スコープの改善Issue #3608へ集約されています。旧版での指摘をそのまま現行版の脆弱性と断定するのではなく、最新コードでも任意のPJ指定を受け付ける経路があるという点を導入試験の対象にします。 3. 共有はどこまでできるのか 「共有」と一口に言っても、Claude-Memには少なくとも四つの異なる仕組みがあります。 仕組み 共有される範囲 標準動作・境界 同じPJ名・Git worktree 同一ユーザー内の関連PJ履歴 親の記憶などを引き継げる。認可境界ではない CLAUDE_MEM_PROJECT_ENVIRONMENTS 複数ディレクトリを共通PJ名にまとめる inheritで読み込む他PJのキーを選べる。検索権限とは別 Cloud Sync 同一cmem.aiアカウントの端末間 有効時はObservation・セッション要約・プロンプト等がSync Hubへ送信される TeamBrain チームメンバーが選んだPJ 共有するPJとbroadcastを選択。ローカルの個人作業ボードとは別 3-1. 名前付きEnvironmentによる「共通」と「個別」 たとえば次のように、案件ごとに名前付きEnvironmentを定義できます。 { "CLAUDE_MEM_PROJECT_ENVIRONMENTS": [ { "name": "customer-a-app", "patterns": ["~/work/customer-a/app/"], "inherit": [] }, { "name": "customer-b-app", "patterns": ["~/work/customer-b/app/"], "inherit": [] } ] } inherit: [] は、フォルダやGit名から自動導出された別の記憶キーをデフォルトの読み込み対象に含めず、そのEnvironmentの記憶を中心にする指定です。 反対に、承認済みの共通知識を読み込みたい場合、次のような構成も可能です。 { "name": "customer-a-app", "patterns": ["~/work/customer-a/app/**"], "inherit": ["shared-practices"] } これは「顧客Aの記憶 + shared-practices として保存した記憶」をデフォルトの参照対象にする考え方です。shared-practices の記録は別途、対応するPJ名として保存されている必要があります。 ただし公式ドキュメントにも、inherit はデフォルトのコンテキスト選択であってアクセス権限ではないと明記されています。 また過去に実施したPJのmergeは引き続き効く可能性があるので、設定変更だけで履歴が切り離されたと判断してはいけません。 3-2. TeamBrainは「すべて自動でチーム共有」ではない TeamBrainは、チームメンバーが共有するPJを選択し、作業リストや関連する発見を共有ワークスペースに表示する機能です。通常の個人用 My Work のレビュー記録がそのままチームへ統合される仕組みではありません。 実装では、共有するPJの選択が空配列なら「共有なし」、null なら「すべてのPJを共有」という区別が見られます。SIerでは「今後作る案件も含めてすべて共有」の設定を誤って選ばない運用が重要です。 一方、TeamBrainの選択共有を導入しても、元となる端末上のローカルWorkerにある全履歴の認可問題が自動的に解消するわけではありません。 3-3. Cloud Syncは個人の複数端末をまたぐ Cloud Syncを有効化すると、端末上の記憶はcmem.aiのSync Hubを通じて同期されます。公式仕様では、Observation、セッション要約、ユーザープロンプト、対応時の作業状態などが対象です。 複数の顧客案件が一つのユーザーデータ領域に保存されていれば、PJを意識しない個人端末間同期の扱いも検討が必要です。顧客Aから顧客Bへの自動注入を防いだとしても、記録のコピー先やデータ管理主体の問題は残ります。 4. SIerとしてどう評価するか 利用場面 判断 理由 公開OSS・学習用環境 導入候補 機密性の低いデータで有用性を検証できる 一般的な社内開発 条件付き 送信先・端末・保存データ・更新の制御が必要 同一開発者による複数顧客の受託開発 標準構成のままでは非推奨 PJフィルターと顧客のアクセス境界が一致しない 金融機関・高機密案件 厳格な隔離が前提 個別環境・通信制御・検証済み版・監査が必要 特に見落としやすいリスクは次のとおりです。 データ収集:プロンプトのほか、ツール入力・出力、エラー、変更背景に機密情報が含まれる。<private> タグは使えるものの、タグを付け忘れた情報の保護にはなりません。自動マスキングは標準で無効なので、有効化と精度検証が必要です。 外部送信:要約時にはAnthropic、Gemini、OpenRouter、CMEM Pro、任意のOpenAI互換エンドポイントなどの設定先へ情報が渡る可能性があります。ローカルSQLiteに保存していても、推論まで端末内で完結しているとは限りません。テレメトリもデフォルトで有効です。 ローカルAPIとログ:Workerは標準でループバックにバインドしますが、同じ端末の別プロセスやポート転送、ローカルに保存されるログ・設定ファイルまで含めて保護する必要があります。 Prompt Injection:不正な文章が記憶として取り込まれると、後のセッションのAIにとって「過去の文脈」に見える可能性があります。メモリは信頼されたシステム指示ではなく、検証可能な参考情報として扱う設計が必要です。 5. SIer向けの推奨構成:既存PC/Windows 365と案件専用Azure VMを使い分ける Claude-Memのメモリを「自動で検索できるように分類する」ことと、「別顧客の情報に技術的にアクセスできない」ことは異なります。そのため、守秘義務が異なる顧客案件間の分離は、メモリの検索条件ではなく、実行環境・OS権限・保存領域・ネットワークの境界で実現する方針が良さそうです。 5-1. 機密区分別の使い分け 利用シーン 推奨する開発環境 Claude-Memの扱い 主な確認事項 公開OSS・学習・低機密PoC 既存の会社管理PC(Windows+WSL2など) ローカルで試験導入 外部通信、端末管理、ダミーデータでの検証 一般的な社内開発 既存の管理PC、またはWindows 365 Cloud PC チーム内の利用方針を定めて導入 Intune・Entra ID・条件付きアクセス、保存データ保護 通常の受託開発 顧客別に割り当てた管理PC/Windows 365、必要に応じてAzure VM 顧客ごとに保存先・認証情報・同期を分ける 複数顧客の同一Cloud PCへの混在を防ぐこと 銀行・高機密・閉域案件 顧客・案件専用Azure VM(WindowsまたはLinux)、要件によって専用VDI 専用ユーザー/VM/DBに限定。外部同期は原則無効 VNet・Private Endpoint、通信制御、ログ、破棄手順 多人数の集中管理VDIが必要 Azure Virtual Desktop(AVD)も比較対象 セッション分離と保存ボリューム分離を検証 マルチセッション時のユーザー間隔離、運用コスト Windows 365は管理された永続Cloud PCを提供し、IntuneやEntra IDと連携できる点が利点です。一方、厳格なネットワーク境界、Linuxネイティブの開発環境、案件別のリソース構成を細かく制御したい場合には、Azure VMのほうが設計しやすいことがあります。MicrosoftがWindows 365を推奨していることと、どのSI案件にもWindows 365が最適であることは同義ではありません。 5-2. 推奨アーキテクチャ この図では、AとBのメモリDBをそれぞれ別のVM内に置きます。個々のWorkerが同じローカルSQLiteを共有しないため、誤ってPJ指定を省略した検索が発生しても、別VMのDBには直ちにアクセスできません。もちろん、これはVM間の権限・ネットワーク・共有ストレージが適切に分離されていることが前提です。 実際の設計では、少なくとも以下の境界をそろえます。 実行・認証の境界:顧客ごとにOSユーザー、VM、SSH/RDPアクセス、Entra ID権限などを分離する。 データの境界:~/.claude-mem/(または CLAUDE_MEM_DATA_DIR の保存先)、ログ、ベクトルDB、バックアップ、認証情報を分離する。 通信の境界:モデルの要約送信先を許可済みのGateway/ローカル推論へ限定し、Cloud Sync、テレメトリ、未承認APIへの通信を制御する。 持ち出しの境界:案件間のメモリ同期やコピペによる移動を原則禁止し、共通化できる設計原則・障害対応手順だけをレビュー後に昇格させる。 なお、Claude-Memの外部通信を制限しても、本体のAIコーディングエージェントが使うLLMやGitHubなどの外部接続は別に管理する必要があります。さらにWindows 365を使う場合も、同じCloud PCで複数顧客案件を扱えばメモリ混在リスクは残ります。Cloud PCという製品名だけで自動的に顧客分離が実現するわけではありません。 5-3. 共通知識は「全PJの記憶を読ませる」のではなく、承認後に配布する 顧客間で再利用すべきなのは、実際の顧客名や内部API、ソースコード断片ではなく、レビューして一般化したテスト手法・設計原則・障害対応パターンなどです。CLAUDE_MEM_CONTEXT_PROJECTS=all や単一メモリDBへの集約で共有範囲を広げる代わりに、元データの守秘義務と持ち出し可否を人が確認してから共通ナレッジを作ります。 将来的に企業共通のAgent Memory基盤を作るなら、顧客・PJ・ユーザーの認可を備えたAPIを別途設け、アクセス権限と記憶の分類を独立して設計する方法が考えられます。 5-4. PoC向けの設定例 次は隔離した検証環境で、デフォルト注入と外部送信をできるだけ抑えて動作確認するための参考例です。 { "CLAUDE_MEM_CONTEXT_PROJECTS": "current", "CLAUDE_MEM_SESSION_START_INCLUDE_ALL_SOURCES": "false", "CLAUDE_MEM_WORKER_HOST": "127.0.0.1", "CLAUDE_MEM_CLOUD_SYNC_HUB_URL": "", "CLAUDE_MEM_REDACT_ENABLED": "true", "CLAUDE_MEM_REDACT_GENERIC_ENABLED": "true", "CLAUDE_MEM_PROJECT_ENVIRONMENTS": [ {"name": "customer-a-app", "patterns": ["~/work/customer-a/app/"], "inherit": []}, {"name": "customer-b-app", "patterns": ["~/work/customer-b/app/"], "inherit": []} ] } テレメトリは別途 DO_NOT_TRACK=1 または npx claude-mem telemetry disable で無効化できます。要約処理を社内推論に限定する場合は openai-compatible プロバイダーを承認済みのローカルまたは社内エンドポイントへ向け、外部へのフォールバックまで含めて通信制御で検証します。実稼働では共有DBに両案件を置くのではなく、上記の実行環境・データ保存先の分離を優先します。 ! このJSONは顧客間のセキュリティ境界を成立させる「完成済み設定」ではありません。inherit: [] は自動読み込みのスコープに関する設定であり、任意のMCP検索、ローカルDBへのアクセス、OS権限、クラウド同期済みデータなどを一括で遮断する機能ではありません。 6. 実際に検証したいテストケース 導入前には、公開情報の確認だけでなく、ダミーデータで越境検索を試すことを推奨します。 No. テスト 合格条件 1 顧客A・Bの二つのPJで異なるダミー記憶を作成 各記憶に想定どおりのPJ名が付く 2 Aのセッションを開始 Bの記憶が自動注入されない 3 Aの状態から search をPJ指定なしで実行 Bを取得できるなら、分離不足と判定する 4 get_observations にBの記憶IDを渡す Bの詳細を取得できるなら、分離不足と判定する 5 A・Bのリポジトリ名を同じにする PJ名の衝突を検出できる 6 worktree・submodule・inheritの組み合わせ 意図しない親・旧キーの記憶を読み込まない 7 EXCLUDED_PROJECTSを設定した後に検索 既存データの扱いを含め、期待した取得制限を確認する 8 Cloud SyncとTeamBrainの共有設定を変更 許可したデータだけが同期・共有される 9 架空のAPIキー・秘密文字列をツール出力に含める ローカルDB、ログ、外部リクエストで露出しない 10 AI推論先を遮断する 未承認の外部プロバイダーへ自動退避しない 11 顧客AとBを別VM/Cloud PCに配置し、AからBのメモリAPI・DBへアクセスを試す アクセスできない。共有マウントや共通バックアップにも抜け道がない 12 案件終了・担当者変更時にメモリDB、ログ、認証情報を棚卸しして破棄する 保持期間・削除証跡・クラウド同期の扱いを説明できる 以下はローカルDBのPJ別レコード件数を確認する例です。架空データのみを利用した隔離環境で実行してください。 sqlite3 ~/.claude-mem/claude-mem.db \ 'SELECT project, COUNT(*) FROM observations GROUP BY project ORDER BY project;' ローカルWorkerの実際のポートを確認したうえで、PJスコープなしの検索と、PJを指定した検索を比較できます。以下の文字列は架空の識別子です。 PORT=$(cat ~/.claude-mem/.worker.port) PJ名を渡さず検索 curl -sG "http://127.0.0.1:${PORT}/api/search" \ --data-urlencode 'query=BOUNDARY_CANARY_B' \ --data-urlencode 'limit=10' PJ Aに明示的に絞って検索 curl -sG "http://127.0.0.1:${PORT}/api/search" \ --data-urlencode 'query=BOUNDARY_CANARY_B' \ --data-urlencode 'project=customer-a-app' \ --data-urlencode 'limit=10' ポートファイルやAPIレスポンスの形式は採用版で確認してください。ここで見るべきなのは、スコープを省略した場合にどの範囲まで検索できるかです。検索でPJ Bが見えるなら、デフォルト注入がAに限定されていても顧客分離としては不十分です。 7. まとめ Claude-Memの「Hookで作業を記録し、LLMで圧縮し、検索して必要な文脈だけ再注入する」という設計は、AI駆動開発の継続性を改善するうえで有用です。Bun、SQLite、Chroma、MCPの組み合わせも、特殊なブラックボックスというより理解・検証可能な構成です。 Claude-MemにはPJ別の分類、選択的な履歴の読み込み、複数PJの意図的な共有、端末間同期、TeamBrainによるチーム共有が用意されています。しかし、ローカルWorkerのPJ指定は基本的に検索・コンテキスト選択の仕組みであり、顧客テナントの認可境界ではありません。 したがって、公開OSSや低機密の社内PoCでは試すのは良いが、複数顧客の機密案件に標準構成のまま横展開することはお勧めできません。 顧客単位でメモリ保存領域と実行環境を分け、承認済みの一般化されたナレッジだけを共通化する方法が現実的です。開発端末については通常開発なら管理された既存PCまたはWindows 365、高機密案件なら顧客専用Azure VMなどで分離することで根本的に混入をさせない構成になりそうです。 参考資料 Claude-Mem GitHub Architecture Overview 設定項目とProject Names PJ識別の実装: project-name.ts Environmentとinherit: project-environments.ts ローカルMCP: mcp-server.ts MCPのcheckoutスコープ: checkout-search-scope.ts 検索フィルター: SessionSearch.ts Cloud Sync TeamBrain Auto-Redaction Security Policy PJ識別・注入スコープ改善Issue #3608 PJ省略時のMCP検索に関するIssue #3764

  2. لاعاد تشرح مشروعك من الصفر كل ما فتحت Claude Code 🦦 فيه ريبو مجاني اسمه claude-mem الاول في GitHub Trending اليوم و110K نجمة: 1- يحفظ ايش سوى الايجنت بالجلسة اللي قبل 2- يرجع له السياق المفيد لحاله 3- يشتغل مع Codex و OpenCode احفظها 🤓 thedotmack/claude-mem

    16 likes · 788 views
  3. Claude Code now has permanent memory 😳 Meet claude-mem (~110K stars) > Remembers your last coding session > Saves context for future sessions > Works with Claude Code, Codex, OpenCode and more try thedotmack/claude-mem t.co

    28 likes · 1 repost · 750 views
  4. t3code Tops GitHub Trending with 3,100 Stars Today What it is !pingdotgg/t3code t3code is the top repository on GitHub trending today, picking up 3,100 stars in a single day. That is more than double the next closest project on the list, and it happened with a repository description that is currently empty. The only signals available are the name, the organization behind it, and the star velocity. The pingdotgg organization is the same one behind the T3 stack ecosystem, which includes create-t3-app and the T3 Turbo monorepo. That context matters because it tells you what kind of codebase to expect: TypeScript-first, opinionated about tooling, and aimed at developers who already work in the React and Next.js world. But the repository itself does not yet ship a description, so anything beyond that is inference. Why it is getting attention The star count is the story. 3,100 stars in a day puts t3code well ahead of every other project on today's trending list. For comparison, claude-mem pulled 1,527, hex pulled 1,329, and Claude-Code-Game-Studios pulled 970. t3code more than doubled the runner-up. That kind of velocity usually means one of a few things. Either a well-known maintainer announced something publicly, a launch post linked here, or the repository is a placeholder that got shared before the actual code landed. The empty description supports the third possibility, though it is not proof. What is clear is that a large number of developers decided this repository was worth starring today, and the star count is the only concrete data point available. It is also worth noting what t3code is competing against on the same day. The rest of the trending list is dominated by AI tooling: persistent memory for coding agents, a headless browser built for automation, an offline speech-to-text app, a local voice dictation tool for three platforms, and an open-source security operations center that ships an MCP server. In that company, a repository with no description still leading the chart is unusual and suggests the T3 name carries real weight with its audience. Who should care Developers already using the T3 stack should watch this repository. If it turns out to be a new scaffolding tool, a runtime, or a component library, it will likely slot into the same workflow as create-t3-app and T3 Turbo. The organization has a track record of shipping tooling that people actually adopt, which is why the star count spiked before any documentation existed. Anyone evaluating TypeScript web tooling more broadly should also keep an eye on it, but with a caveat. Without a description, a README, or a release, there is not enough information to recommend adoption. Starring a repository is cheap. The useful next step is to wait for the maintainers to publish what the project actually does, then decide whether it fits your stack. If you are looking for something you can use today, the other entries on the trending list are more concrete. claude-mem has a clear description of persistent context across agent sessions. hex and Handy both ship offline voice input. AiSOC documents alert fusion and a replayable decision ledger. t3code, by contrast, is a signal without a payload, at least for now. The 3,100 stars are real. The project's purpose is not yet public. That gap is exactly why it is worth following rather than adopting. View the repository on GitHub

  5. 今日のGitHubトレンド thedotmack/claude-mem Claude Code向けの永続的メモリ圧縮システムです。 ツール使用時の情報を自動的に取得して要約し、セッション間でコンテキストを保存することで、セッション終了後や再接続後でもプロジェクトに関する知識の継続性を維持することを目的としています。

  6. Trending repository of the day 📈 claude-mem Persistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into... Last 24h: 1,723 ⭐ Total: 107,020 ⭐️ thedotmack/claude-mem

    23 likes · 2 reposts · 2,385 views
  7. How to Use Claude-mem for Memory Persistence in Claude Code Persistent Memory in AI-Assisted Development with Claude-mem What if your AI assistant remembered every architectural decision, bug fix, and refactoring session across weeks of development? Claude-mem eliminates the friction of lost context by automatically capturing tool usage observations, compressing them into semantic summaries, and injecting relevant history into every new Claude Code session. {% cta apidog.com %} Try Apidog today {% endcta %} The Problem: Context Amnesia in AI-Assisted Development Every Claude Code session starts as a blank slate. When you close your terminal or disconnect from a session, Claude forgets everything; your project structure, recent refactoring decisions, debugging discoveries, and architectural patterns. This forces you to repeatedly explain your codebase, burning tokens on redundant context and breaking workflow continuity. Developers currently work around this by manually maintaining CLAUDE.md files, jotting notes in separate documents, or re-explaining project context at the start of every session. These approaches are brittle, time-consuming, and never capture the full richness of your development history. Claude-mem solves this by automatically observing every tool invocation, compressing the output into searchable semantic memories, and intelligently retrieving relevant context when you need it. Understanding Claude-mem's Architecture Claude-mem operates as a persistent memory compression system that hooks into Claude Code's lifecycle. It captures tool outputs—typically 1,000 to 10,000 tokens—and compresses them into roughly 500-token semantic observations using Claude's Agent SDK. These observations are categorized by type (decision, bugfix, feature, refactor, discovery, change) and tagged with relevant concepts and file references, then stored in a local SQLite database with full-text search capabilities. The system uses five lifecycle hooks to capture context: - SessionStart: Injects context from previous sessions when you begin - UserPromptSubmit: Captures your queries for pattern recognition - PostToolUse: Observes every tool execution and its output - Stop: Generates session summaries when Claude finishes responding - SessionEnd: Finalizes session storage and cleanup This architecture enables progressive disclosure—a layered memory retrieval system that balances coverage with token efficiency. Instead of dumping your entire history into context, Claude-mem retrieves observations in layers, saving approximately 2,250 tokens per session compared to manual context management. Installation and System Requirements Claude-mem requires Node.js 18.0.0 or higher, the latest Claude Code with plugin support, and Bun as the JavaScript runtime and process manager (auto-installed if missing). SQLite 3 is bundled for persistent storage. The plugin works cross-platform on Windows, macOS, and Linux. Quick Start Installation Install Claude-mem directly from the plugin marketplace with two commands: /plugin marketplace add thedotmack/claude-mem /plugin install claude-mem Restart Claude Code after installation. The plugin automatically downloads prebuilt binaries, installs dependencies including Bun and SQLite, configures hooks for session lifecycle management, and auto-starts the worker service on your first session. Advanced Installation from Source For development or testing, clone and build from source on GitHub: git clone https://github.com/thedotmack/claude-mem.git cd claude-mem npm install npm run build npm run worker:start This approach is useful if you need to modify the plugin or run beta features like Endless Mode. Post-Installation Verification After installation, verify everything is working: 1. Check plugin installation: cat plugin/hooks/hooks.json 2. Verify the worker service is running: curl http://localhost:37777/api/health 3. View recent worker logs: npm run worker:logs Test context retrieval by starting a new Claude Code session. You should see context from previous sessions automatically loaded in the initial prompt. Data Storage and Configuration Claude-mem stores all data locally in ~/.claude-mem/: - Database: ~/.claude-mem/claude-mem.db (SQLite with FTS5 search) - PID file: ~/.claude-mem/.worker.pid - Port file: ~/.claude-mem/.worker.port - Logs: ~/.claude-mem/logs/worker-YYYY-MM-DD.log - Settings: ~/.claude-mem/settings.json Override the default data directory with an environment variable: export CLAUDE_MEM_DATA_DIR=/custom/path Configuration Options Settings are managed in ~/.claude-mem/settings.json (auto-created on first run). Key configurations include: - CLAUDE_MEM_CONTEXT_OBSERVATIONS: Number of observations injected at session start (default: 50) - CLAUDE_MEM_FOLDER_INDEX_ENABLED: Enable/disable auto-generated CLAUDE.md files in folders - Model selection for AI-powered compression - Worker port and host settings - Log level configuration How Claude-mem Captures and Processes Context When you use Claude Code with claude-mem enabled, the system captures every tool invocation automatically. Whether Claude reads a file, executes a bash command, searches with glob patterns, or edits code, claude-mem observes the input and output. The worker service processes these observations and extracts: - Title: Brief description of what happened - Subtitle: Additional context - Narrative: Detailed explanation of the activity - Facts: Key learnings as bullet points - Concepts: Relevant tags and categories for search - Type: Classification (decision, bugfix, feature, refactor, discovery, change) - Files: Which files were read or modified This compression happens automatically without manual intervention. The raw tool output might be 5,000 tokens, but the semantic observation stored in the database is roughly 500 tokens—preserving meaning while eliminating noise. Session Summaries When Claude finishes responding (triggering the Stop hook), claude-mem automatically generates a session summary containing: - Request: What you asked for - Investigated: What Claude explored to answer - Learned: Key discoveries and insights - Completed: What was accomplished - Next Steps: Recommended follow-up actions These summaries are injected into future sessions alongside individual observations, providing both granular detail and high-level narrative context. Using MCP Search Tools to Query Your Memory Claude-mem exposes four MCP tools that follow a token-efficient 3-layer workflow pattern. This design retrieves context progressively, minimizing token usage while maximizing relevance. The 3-Layer Workflow 1. search: Get a compact index with IDs (~50-100 tokens per result) 2. timeline: Get chronological context around interesting results 3. get_observations: Fetch full details ONLY for filtered IDs (~500-1,000 tokens per result) This approach achieves approximately 10x token savings by filtering before fetching full details. Available MCP Tools - search: Search the memory index with full-text queries. Filter by type, date, or project. - timeline: Get chronological context around a specific observation or query. - get_observations: Fetch full observation details by IDs. Example Usage Patterns Find a specific bug fix: # Step 1: Search for the bug search(query="authentication bug", type="bugfix", limit=10) # Step 2: Review index, identify relevant IDs (e.g., #123, #456) # Step 3: Fetch full details for relevant observations get_observations(ids=[123, 456]) Explore recent architectural decisions: search(query="database schema", type="decision", limit=5) Find everything related to a specific file: search(query="worker-service.ts", limit=20) Natural Language Queries You can ask Claude naturally about your project history: - "What did we decide about error handling?" - "How did we implement authentication?" - "What bugs did we fix in the API layer?" - "Show me changes to the database schema" Claude automatically invokes the appropriate MCP tools to retrieve relevant context, presenting findings with claude-mem:// URI citations that reference specific observations. Folder Context Files and CLAUDE.md Auto-Generation Claude-mem automatically generates CLAUDE.md files in project folders, creating activity timelines that complement the global memory database. How Folder Context Works When you work with files in a folder, claude-mem: 1. Identifies unique folder paths from touched files 2. Queries recent observations relevant to each folder 3. Generates a formatted timeline of activity 4. Writes it to CLAUDE.md in that folder (inside <claude-mem-context> tags) Each folder's CLAUDE.md contains a Recent Activity section showing observation IDs, timestamps, type indicators (bug fixes, features, discoveries), brief titles, and estimated token counts. Example CLAUDE.md Structure # Authentication Module This folder contains all authentication-related code. Follow the established patterns for new auth providers. <claude-mem-context> # Recent Activity | ID | Time | Type | Title | Tokens | |----|------|------|-------|--------| | #1234 | 4:30 PM | 🔵 | Implemented user authentication | ~250 | | #1235 | 4:45 PM | 🔴 | Fixed login redirect bug | ~180 | </claude-mem-context> ## Manual Notes - OAuth providers go in /providers/ - Session handling uses Redis Web Viewer UI and Real-Time Monitoring Claude-mem runs a web viewer at localhost for real-time memory stream visualization. The interface shows: - Live observation stream with emoji indicators for importance - Session timeline with chronological markers - Search interface for querying memories - Settings panel for configuration adjustments Troubleshooting Common Issues Worker Service Not Starting If the worker fails to start on port 37777: 1. Check if the port is already occupied: lsof -i :37777 2. Configure an alternative port: export CLAUDE_MEM_WORKER_PORT=8080 3. Manually start the worker: bun plugin/scripts/worker-service.cjs Memory Not Being Saved If Claude doesn't remember previous sessions: 1. Verify the worker is running: npm run worker:status 2. Check the database file exists: ls -la ~/.claude-mem/claude-mem.db 3. Review worker logs for errors: npm run worker:logs Empty CLAUDE.md Files If claude-mem creates empty CLAUDE.md files throughout your project, this is a known issue in v9.0.5. Current workarounds include manually deleting created directories, adding patterns to .gitignore, or waiting for the fix in a subsequent release. Conclusion Claude-mem transforms Claude Code from a stateless assistant into a persistent development partner that accumulates knowledge about your codebase over time. By automatically capturing tool usage, compressing observations into searchable memories, and intelligently retrieving relevant context, it eliminates the repetitive context-building that slows down AI-assisted development. When building APIs or working with external services in your Claude-mem enhanced workflow, streamline your testing with Apidog. It offers visual API testing, automatic documentation generation, and collaborative debugging that complements your persistent memory setup.

  8. claude-mem: a Chinese translation of the persistent-memory layer for Claude Code Every time you open a new Claude Code session, the model starts from zero. It doesn't remember that you already fixed the auth bug two hours ago, or which file holds the retry logic, or why you rejected the first approach. You re-explain, it re-reads, and the loop repeats. claude-mem is a project that tries to close that gap. The upstream repo is thedotmack/claude-mem, written in TypeScript, Apache-2.0 licensed, with 105,900 stars. A Chinese translation of its documentation was published today at yangshun2005/claude-mem-cn. That translation is what I want to look at here — not because the translation itself is technically interesting, but because of what it changes for a specific group of developers. What the project actually does The one-line description from upstream is: "Persistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions." Stripped of the marketing, the mechanism is: 1. Capture. During a Claude Code session, claude-mem records "observations" about tool usage — what the agent read, ran, changed. 2. Compress. Those raw observations get summarized into semantic form. 3. Inject. In later sessions, relevant pieces of that compressed memory are fed back into context. The stated goal is knowledge continuity: Claude keeps a working model of the project across session boundaries and reconnects. It's advertised as working with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode and others. That's the whole pitch. Whether the compression is good enough to be useful rather than noisy is something you'd have to judge on your own codebase — I haven't benchmarked it, and the README doesn't publish accuracy numbers. Install path The primary install command from the README: npx claude-mem install For Grok Bot there's a separate invocation: npx claude-mem install --ide grok-bot The installer configures the environment first, then asks you to log in through the browser using an email magic link. No credit card. Login assigns your account a memory key and unlocks the claude-mem observer with a 30-day free trial. After login you pick a memory provider: - claude-mem observer (the hosted option) - your own OpenRouter key - your own Gemini key - your Anthropic plan If you'd rather not log in at all, the README lists three escape hatches: pass --provider explicitly, set CLAUDE_MEM_ONLINE_OPTIN=false, or run in a CI / non-interactive environment. The README text is truncated at that point, so the full non-interactive details aren't documented in what I have. Node.js >=20.0.0 is the dependency floor. Current version is 15.7.0. The README doesn't state which operating systems are supported or what hardware it wants — that's a gap, not an omission on my part. The parts that will bite you Three things in the README are worth reading twice before you install. The trial expires. The claude-mem observer is a 30-day free trial. When it ends, memory functionality falls back to your Anthropic plan unless you subscribe. If you're evaluating this for a team, that's a cost decision you should make up front rather than discover in month two. Grok Bot works differently. Grok Bot has no host hooks, so claude-mem watches chat log files instead. It defaults to hosted CMEM Pro; the local observer requires --provider host to be turned on explicitly. Installing that plugin does not install Cursor. Awareness push writes to disk. For Grok Bot, key observations — decision, bugfix, security_alert, sensitive — get appended as dated - YYYY-MM-DD [awareness] … lines into memory/log/YYYY-MM.md. Grok Bot already re-reads logs from disk. This does not write to profile.md, user memory, or project memory. You can disable it with CLAUDE_MEM_GROK_BOT_AWARENESS_ENABLED=false. That last one matters if you care about what lands in your repo. A log file accumulating security-flagged observations is exactly the kind of thing you want to know about before it's committed. Why a Chinese translation is more than a convenience Here's the part I actually want to argue. The upstream README is long. It has a 30-language selector strip, a quick start, a "how it works" section, search tools, docs, configuration, and troubleshooting. For an English reader that's a lot of scrolling. For a Chinese-speaking developer it's worse: you're parsing configuration semantics in a second language while simultaneously trying to decide whether the tool fits your workflow. Those are two different cognitive loads, and doing them at once is how people misread --provider host as optional. The claude-mem-cn repo does something slightly smarter than a straight translation. It splits the page into two layers: - A 中文快速上手 section at the top, explicitly marked as supplementary material, not part of the original. This is a curated导读 — what the project is, what problem it solves, the shortest path to running it, environment requirements, and common pitfalls. - The translated README body below, which the maintainer states aims to stay faithful to the original. That distinction is stated openly in the README: "本页顶部的「中文快速上手」为面向中文用户的补充导读(非原文内容)" — the top section is a guide for Chinese users, not original content. And: "如有翻译不准确之处,欢迎提 Issue 或 PR" — inaccuracies should go to issues or PRs. I like this because it's honest about provenance. A translation that silently blends editorial additions into the source text is worse than useless; you can't tell which claims are the project's and which are the translator's. Here the boundary is drawn in the document itself. The quick-start section also front-loads the things that would otherwise cost you an hour: that login is required by default, that the free trial has an end date, that Grok Bot has different constraints, that awareness push can be turned off. Those are all in the English README too, but scattered. Collecting them into one screen is the actual value-add, more than the translation itself. What the translation doesn't solve Two honest caveats. First, the quick-start section inherits the same truncation as the source. The non-interactive install path is described as "原文此处被截断,后续细节未说明" — the original is cut off there, details not given. So if you're trying to wire this into CI, the Chinese version won't get you further than the English one. You'll need to read the source. Second, the translation is dated 2026-10-31 and the project is at 15.7.0. Fast-moving repos drift. If you're reading this much later, check whether the Chinese README still matches upstream before trusting a specific flag name. Should you try it If you use Claude Code on a project that spans multiple sessions — which is most real projects — the problem claude-mem addresses is real. Session amnesia is annoying and it costs tokens. Whether claude-mem is the right fix depends on things the README can't tell you: how well the compression holds up on your codebase, whether the hosted observer is worth a subscription after the trial, and whether you're comfortable with observations being written to log files in your repo. My sample of one README is not enough to answer any of those. What I can say is that the Chinese translation lowers the entry cost meaningfully. If your team reads Chinese and has been putting off evaluating this because the docs are dense English, the barrier just got smaller. The install is one command, the trial is 30 days, and the pitfalls are now listed in one place at the top of the page. That's a reasonable place to start. - Original: thedotmack/claude-mem — 105,900 stars, TypeScript, Apache-2.0 - Chinese version: yangshun2005/claude-mem-cn — published today --- *Chinese documentation: yangshun2005/claude-mem-cn* I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

  9. Your agent forgets everything the second the session ends, doesn't it. Claude-mem gives every agent persistent memory — it captures what happens in a session, compresses it with ai, and injects the relevant bits next time you start. thedotmack/claude-mem

    7 likes · 207 views
  10. Give Claude Code a memory between sessions with claude-mem Every new Claude Code session starts blank. You re-explain the architecture, the decision you made on Tuesday and the bug you already ruled out. claude-mem is a persistent memory plugin that captures what Claude did, compresses it into summaries, and feeds the relevant parts back into later sessions. The short version is on the Deduped use-case page. Here is the install and how to use it, using the commands in the README. What it does Per the README, claude-mem automatically captures tool usage observations, generates semantic summaries, and makes them available to future sessions. Claude keeps continuity of knowledge about your project even after a session ends or reconnects. Search is layered (progressive disclosure), so you can see the token cost of what you pull in. Install The one-command route: npx claude-mem install The installer sets everything up, then offers a browser sign-in for the hosted memory option. You can skip that: pass an explicit --provider flag, set CLAUDE_MEM_ONLINE_OPTIN=false, or run it in CI or a non-interactive shell and it completes without any account step. After sign-in you choose a memory provider: the claude-mem observer, your own OpenRouter or Gemini key, or your Anthropic plan. Or install from the plugin marketplace inside Claude Code: /plugin marketplace add thedotmack/claude-mem /plugin install claude-mem Restart Claude Code. Context from previous sessions will appear in new sessions automatically. One warning from the README: npm install -g claude-mem installs only the SDK and library. It does not register the plugin hooks or start the worker service. Use npx claude-mem install or the /plugin commands. Other tools it supports The same installer takes an --ide flag: npx claude-mem install --ide opencode npx claude-mem install --ide t3code npx claude-mem install --ide antigravity npx claude-mem install --ide omp npx claude-mem install --ide pi For OpenClaw gateways there is a separate script, described on the OpenClaw use-case page. Using it day to day Start a new session in a project you worked on yesterday. Previous context shows up on its own. When you need something specific, ask Claude to search memory, for example "what did we decide about the auth middleware last week." The README describes a three-step mem-search skill for this, and there is a walkthrough in searching past decisions in Claude Code. Keep secrets out claude-mem has a privacy control: wrap sensitive text in the exclusion tags described in the README and it is not stored. Do this for anything like tokens or customer data before you rely on it. Things to know before you rely on it - It runs a local worker service, so expect an extra background process. - Summaries are generated by a model provider you pick, which affects cost and where your session text goes. Pick deliberately. - Restart your tool after installing, or the hooks will not load. If you only want Claude to follow better rules rather than remember more, pair it with a short CLAUDE.md. For more repos in this category see the Deduped page for claude-mem. Want the setup commands for 50 AI repos people actually ship with? Get the free AI Repos That Actually Ship pack: dedupedai.com

    1 reaction
Trending awards, every completed day and week
Gold
11st place finishes
Silver
22nd place finishes
Bronze
33rd place finishes
Awarded repositories
2Owned by thedotmack now

Repositories

Ordered by gold, then silver, then bronze.

  1. awesome-claude-codeBest: 1st by forks, 1 forks100
  2. claude-memBest: 2nd by stars, 588 stars023

A repository earns an award for finishing first, second or third in a completed trending day or week, ranked by new stars, new forks or pull request authors. Awards follow a repository through renames and transfers and count toward its current owner. Weeks run Monday to Sunday, UTC.