Lotor

Name: Lotor
Author: githubscum

作者：githubscumバージョン 1.0.2i★ –iパソコンで動く

レジストリ名io.github.githubscum/lotor

インストール

概要

作者による説明（英語の原文）

A local receipt and approval gate for AI agent sessions. The agent can act, but it cannot sign.

PopNx MCPの3つの柱

この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。

利用者の声iレビューはまだありませんレビューは今後のステップで、アカウント機能と一緒に始まります
私たちの基本チェックi1項目中1項目に合格公開情報からチェック。コードはまだスキャンしていません
利用状況i未計測★ –

できること

このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。

接続方法: パソコンで動く
トランスポート: stdio
カテゴリ: その他

インストール

使っているAIアプリを選んで、設定をコピーしてください。

インストールの前に

基本チェック：1項目中1項目に合格
あなたのパソコンで、あなたのユーザーと同じ権限（ファイル、ネットワーク、アプリ）で動きます。
レジストリには、入力が必要なキーは載っていません。

必要なもの

npmNode.jsのインストール（npxコマンドに必要）

どのアプリを使っていますか？

ClaudeClaude CodeCursorVS CodeChatGPT

上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。

Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます

{
  "mcpServers": {
    "lotor": {
      "command": "npx",
      "args": [
        "-y",
        "lotor-mcp"
      ]
    }
  }
}

ターミナルでこれを実行します

claude mcp add lotor -- npx -y lotor-mcp

Cursorで開く

または、設定を自分でコピーする

プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます

{
  "mcpServers": {
    "lotor": {
      "command": "npx",
      "args": [
        "-y",
        "lotor-mcp"
      ]
    }
  }
}

ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。

VS Codeで開く

または、設定を自分でコピーする

プロジェクトの .vscode/mcp.json に貼り付けます

{
  "servers": {
    "lotor": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "lotor-mcp"
      ]
    }
  }
}

これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。

選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。

この設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。

できること

パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。

基本チェックi

誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月6日にチェック

✓ 合格
作者とリポジトリが一致
レジストリ名は、リポジトリを所有するGitHubアカウント githubscum で確認済みです
… 未チェック
今もメンテナンスされている
このリポジトリはまだGitHubから読み取っていません
… 未チェック
ライセンスがある
このリポジトリはまだGitHubから読み取っていません
– 対象外
エンドポイントが応答する
これはパソコンで動くため、インターネット上のエンドポイントはありません
– 対象外
OAuthでサインイン
パソコンで動き、代わりにローカルの設定を使います
… 未チェック
ツールの説明に隠れた指示がない
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです

その他のほかのサーバーとの比較i

このカテゴリのほかの32398件のうち0%よりスターが多い
このカテゴリのほかの32398件のうち19%より最近レジストリに公開
基本チェックの結果が、このカテゴリのほかの32398件のうち100%と同じかそれ以上

レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。

よくある質問

Lotorは安全ですか？

当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。

どんなキーやコードが必要ですか？

レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。

パソコンで動きますか、それともクラウドですか？

あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません（サーバー自体がオンラインサービスを呼び出す場合を除きます）。

今もメンテナンスされていますか？

GitHubリポジトリの最終更新は–、最新バージョン（1.0.2）がレジストリに届いたのは3 か月前です。

どのアプリで使えますか？

Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにNode.jsも必要です。

代わりに使えるものは？

同じカテゴリには：Spec Driven Development, Remote Desktop Commander, AI Deprecations

代わりの候補

同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。

カードの見方：★ GitHubスターi3つの柱：レビュー · チェック · 利用状況i更新＝最新バージョンをレジストリに公開した日i

Spec Driven Development

作者：formulahendry

MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.

パソコンで動く★ 440MIT14 か月前更新

インストール

Remote Desktop Commander

作者：desktop-commander

Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.

クラウドで動く★ 211昨日更新

インストール

AI Deprecations

作者：aideprecations.com

AI model shutdown dates, replacements, change feed and webhook alerts for 8 providers.

クラウドで動く今日更新

インストール

作者のREADME

READMEを開く

作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。

Lotor

A local receipt and approval gate for AI agent sessions. The agent can act, but it cannot sign.

What it is

Lotor writes a signed, tamper-evident log of what an agent did during a session: actions performed, files touched, messages sent, costs incurred, failures encountered. The log lives on your machine, in a format you can inspect, verify and archive.

It does not prove the agent's actions were correct. It records them, and makes later tampering detectable.

It also gates the actions you choose. Those stop and wait for an approval signed with a passphrase the model has never seen and cannot derive. An agent can request a consequential action. It cannot authorize one.

Local first, and not as a deployment option. The receipt is written to your machine and nowhere else. No upload path, no account, no server component. Nothing leaves because nothing is built to send it. Much accountability tooling is cloud observability, which means your agent's history becomes inventory in someone else's books. Lotor is not the only local one: Obsigna (agentreceipts.ai) ships a local, signed, tamper-evident record with a Claude Code hook, is formally verified, and predates this repo. What this repo adds on top of a record is the gate that blocks until a human signs, and a ledger that confesses its own limits. The record of what your machines did for you should answer to your key, not to a vendor's retention policy.

Longer arguments for why that matters live at ikeanalytics.com, including the measurement behind them. This file is about running the thing.

What you use it for

Know what ran. Ask the record instead of re-reading transcripts. It is cheaper than reconstruction and it is not subject to the agent's account of itself. A worker in this project once reported which model it was running on, in the section of its own report reserved for admitting uncertainty, and was wrong. The receipt was not.

Sleep through it. Wake up to a signed account of an unattended run rather than a pile of transcripts you will never read.

Stop the expensive ones. Deletes, deploys, sends and spends fail closed until you sign that exact action with its exact parameters. The denial and the approval are both receipted.

Hold your own copy. When a client, vendor or counterparty disputes what happened, the record is yours. Their books, and now yours.

Claim discipline

Measurement, not indictment. A receipt records what the session self-reports. It does not judge intent and it does not catch silent failures.

Self-attested capture. The log begins at signing time. What happened before that moment is not covered by the chain.

Nothing written in the present tense here is unbuilt. Anything not built is named as pending, in the same breath, either below or in KNOWN-LIMITS.md.

Herding modes

When multiple agents coordinate, they should be treated as cattle, not pets. Lotor is built for that.

One agent is easy to trust. It acts on the intent you gave it, and the modes below only ever restate that intent. Put agents to work together and the picture changes. Herds move in ways no single animal chose, and people do the same: in a crowd they get carried along and decide things that cut against what they would choose alone. A gated action is not a verdict on any one agent. It is the fence that holds while the herd moves.

Ten matchers is not a posture anyone can hold in their head. Three presets replace the matrix with one choice.

Mode	Posture	Egress rules (push, publish, egress-other, opaque-exec)	Local-only rules (destructive, scope-escalation)
Herded	the pen	gate	gate
Grazing	the fence, and the default on a fresh install	gate	warn
Loose	the open field	warn	warn

self-mod and mode-change gate in every mode, with no exception. Loose means free to act on the world, not free to rewrite what stops you. An agent in Loose still cannot edit the gate, its policy, its hooks, or switch modes without your signature.

Loose never turns a rule fully off. It warns, which still appends a receipt. The alternative would make the most dangerous mode the one that leaves the least evidence, since an unmatched rule takes a fast path with no chain write.

npm run mode              # print the current mode and its rule-by-rule expansion

npm run mode -- herded # switch (requires your approval passphrase at a real terminal)

The mode in force is stamped into every session's opening receipt, so a switch is never invisible after the fact. An existing policy.json from before this feature is not silently upgraded: it keeps its rules and loads as mode custom.

Honest limit. Lotor's mode is independent of your harness's own permission mode and the two do not compensate for one another. Loose plus a harness set to bypass its own checks is genuinely nothing stopping anything on either layer. Lotor warns when it sees that combination and records the posture once per session. Detection is not protection. See KNOWN-LIMITS.md item 15.

Install

Installing Lotor means opting into two invariants: the record is written to your machine and nowhere else, and the actions you put behind the gate fail closed until you sign them. Everything below is a choice about *where* those happen, not *whether*.

Read the second one precisely. The gate covers the rules you have set to gate, matched on tool name and parameters. It is not a claim that nothing can leave your machine. See KNOWN-LIMITS.md item 11 for what the matcher does and does not catch, and check lotor_status for which rules are gated versus merely warned on your install.

Lotor is two pieces that install separately. An MCP server, which gives you the tools to query, verify and approve. And four Claude Code hooks, which are what actually record and what actually gate. Installing one without the other is the most common way to end up thinking Lotor is running when it is not.

Prerequisites

Node 18 or later, and a working claude CLI if you are installing into Claude Code.
A text editor, and willingness to hand-edit a JSON file. This is the one that surprises people, so it is stated here rather than discovered at step 5.

Why Lotor does not install its own hooks. It could. It deliberately does not. A tool that can silently register its own enforcement into your settings is a tool that can silently unregister it, and a gate you did not knowingly install is a gate you have no reason to trust. The settings file is inside your threat model, not outside it. The cost is one paste. The benefit is that you know exactly what is running.

1. Where it runs

Install target	What it can receipt	Reach
Claude Code, user scope	every Claude Code session, in every project	widest, always on
Claude Code, project scope	only sessions started inside that one repo	scoped to a project
Claude Desktop extension (`.mcpb`)	Claude Desktop app sessions	the desktop app

claude mcp add lotor -s user -- node /absolute/path/to/lotor/src/mcp/server.js

Use -s project instead to wire Lotor into a single repo, which writes a committed .mcp.json there. For the one-click desktop path see MCP-SETUP.md.

2. Where receipts live

Lotor keeps one canonical store so your chain never fragments. By default ~/.lotor, or %USERPROFILE%\.lotor on Windows. Every CLI and the MCP server read and write that same store regardless of which directory the client launched from. Override with LOTOR_HOME.

Keep this on real local disk. Point LOTOR_HOME at a synced cloud folder and you have handed your receipt log back to a third party, which is the exact custody Lotor exists to remove.

3. Activate it

Clients load MCP servers at session start. Restart your session or open a new one. Restarting the session you installed from is enough.

4. First run: set your key

npm run setup

Setup creates your log-integrity key, then walks you through setting a passphrase for your approval key. The approval key's private half is never written to disk. It is derived from your passphrase at the moment you approve an action, and nowhere else.

Setting the key does not arm the gate. The key is what a signature is made of. The hooks are what stops an action and asks for one. A Lotor install with a passphrase set and no hooks registered records nothing and blocks nothing. Do step 5.

5. Register the hooks (required)

This is the step that turns Lotor from a library into a gate. Skip it and you have installed a query tool against an empty log.

Open your Claude Code settings file (~/.claude/settings.json, or %USERPROFILE%\.claude\settings.json on Windows) and merge in the block below, substituting your own absolute path. If the file already has a hooks key, add these four events inside it rather than replacing it. Forward slashes work on every platform, including Windows.

"hooks": { "SessionStart": [ { "hooks": [ { "type": "command", "command": "node /absolute/path/to/lotor/bin/hook-session-start.js" } ] } ], "PreToolUse": [ { "hooks": [ { "type": "command", "command": "node /absolute/path/to/lotor/bin/hook-pre-tool-use.js" } ] } ], "PostToolUse": [ { "hooks": [ { "type": "command", "command": "node /absolute/path/to/lotor/bin/hook-post-tool-use.js" } ] } ], "SessionEnd": [ { "hooks": [ { "type": "command", "command": "node /absolute/path/to/lotor/bin/hook-session-end.js" } ] } ] } }

Hook	What it does	What is missing without it
`SessionStart`	opens the record: session id, policy in force, chain head, hook registration	a session that dies badly leaves no trace, and the log looks clean
`PreToolUse`	the gate: gated rules fail closed until you sign	nothing is ever blocked, whatever your policy says
`PostToolUse`	captures egress-shaped calls as they complete	outbound activity is only ever reconstructed later
`SessionEnd`	closes the record: what ran, what it touched, what it cost	no session receipt is written

If you would rather not edit JSON by hand, the interactive claude CLI has a /hooks command that writes the same file through a menu.

Restart your session after editing. Hooks are read at session start, so the edit takes effect on the next one.

None of these hooks can break your session. None exits non-zero except the gate, and only when it is blocking on purpose. None writes to stdout. Every other failure is swallowed with a one-line note to stderr. A receipt layer that can wedge your editor is worse than no receipt layer.

Two things to be clear-eyed about. Hook registration lives in a file you can edit, so it is part of your threat model. SessionStart snapshots which hooks were present, so a between-session edit shows up at the next start. And the gate only covers tool calls made after its hook is loading.

6. Confirm it is live

npm run receipts

Look at the SESSION OPENS block. During a live session you should see one more opened than closed: that is your current session. If it reads `Opened: 0`, the `SessionStart` hook is not registered and step 5 did not take. Inside Claude, the lotor_status tool reports the same thing.

If you skip step 5 entirely, nothing is recorded automatically and you are back to ingesting a transcript by hand with npm run ingest -- /path/to/session.jsonl.

Delegation grants

A single-use approval covers one exact command and is spent once. That is right for a deploy and wrong for a working session: forty gated actions means forty trips to a terminal, and a gate that expensive gets switched off, which is the failure it existed t

冒頭だけを表示しています。続きはリポジトリで読めます

Lotor

概要

PopNx MCPの3つの柱

できること

インストール

インストールの前に

できること

基本チェックi

作者とリポジトリが一致

今もメンテナンスされている

ライセンスがある

エンドポイントが応答する

OAuthでサインイン

ツールの説明に隠れた指示がない

その他のほかのサーバーとの比較i

よくある質問

代わりの候補

Spec Driven Development

Remote Desktop Commander

AI Deprecations

作者のREADME

Lotor

What it is

What you use it for

Claim discipline

Herding modes

Install

Prerequisites

1. Where it runs

2. Where receipts live

3. Activate it

4. First run: set your key

5. Register the hooks (required)

6. Confirm it is live

Delegation grants