Casefile

複数のセッションにまたがるタスクをエージェントに任せているすべての方へ。 無料で利用できます。Claude Code向けに作られていますが、Codex、Cursor、その他のMCPクライアントも同じ方法で接続できます。

macOS / Linuxへのインストール

curl -fsSL https://raw.githubusercontent.com/azimov777/casefile/main/install.sh | sh

Windowsへのインストール（PowerShell）

irm https://raw.githubusercontent.com/azimov777/casefile/main/install.ps1 | iex

必要なのはDockerだけです。ボードは http://localhost:8080 で開きます。インストーラーがClaude CodeとCodexを自動で接続するので、プラグインとOAuthサインインだけで済み、トークンをコピーする必要はありません。Casefileは新しいリリースが公開されると自動更新されます。1時間ごと、およびDockerの起動時に確認します。これを行う小さなupdaterサービスがDockerソケットを保持します。更新を無効にできます。

エージェントにインストールを任せることもできます。 これをClaude Code、Codex、またはCursorに貼り付けてください。

https://raw.githubusercontent.com/azimov777/casefile/main/docs/agent-install.md の手順に従って、Casefileをインストールしてください。

理由

セッションが終了したり、コンテキストがいっぱいになったりすると、次のエージェントは最初から作業を始めます。コードを読み直し、すでに失敗した方法を再試行し、すでに回答した質問をもう一度尋ねます。

Casefileはすべてのタスクにケースファイルを用意します。これは、エージェントが作業中に書き込む追記専用のログです。

• 新しいコンテキストでも引き継ぎを維持。 次のエージェントは最新の要約、未解決の質問、ケースの索引を読んでから作業を続けます。調査をやり直す必要はありません。
• エージェント向けにMCP経由で設計。 エージェントはタスクの作成や分割、判断や行き詰まりの記録、質問、各チェックの判定を添えたタスクの完了ができます。
• あなたも状況を把握できます。 リアルタイムのボードとタスクページで、各エージェントの作業状況を確認できます。ブラウザーから質問に回答し、コメントを残し、各エージェントに個別のアクセス権を付与できます。
• ガードレールはあっても、煩雑な手続きはありません。 要約と各チェックの合格判定がなければタスクを完了できず、ブロック中のタスクは開始できません。それ以外は何もありません。スプリント、見積もり、自動化はありません。
• あなたのマシンで、あなたのものとして。 Dockerでローカルに実行し、localhostのみで待ち受けます。サインインを有効にして自分のサーバーに配置し、チームで利用する場合（ネットワークモード）を除き、データがコンピューターの外に出ることはありません。

## 他との違い

• 単なるメモファイルではありません。 CLAUDE.md や handoff.md は上書きされます。2日前に失敗した試みは消え、2つのセッションが同じファイルを編集することになります。ケースファイルは追記専用です。修正は、古い記録を参照する新しいエントリーとして追加します。リポジトリごとのルールには CLAUDE.md を使い、Casefile はタスクごとに使います。
• メモリーサーバーではありません。 Memory MCP は類似性に基づいて事実を思い出します。Casefile は巧妙な検索を行いません。タスクごとの作業ログであり、カード、最新の要約、未解決の質問、インデックスの順に読み、その後、必要なエントリーだけを読みます。
• MCP を後付けした課題トラッカーではありません。 課題は説明と、誰でも編集できるスレッドで構成されます。Casefile のエントリーは型付きで、編集されることはありません。また、記録を損なう書き込みはトラッカーが拒否します。
• オーケストレーターではありません。 エージェントの起動、タイマーの実行、タスクの自動移動は行いません。作業の割り当てやセッションが停止したことの検知は、引き続きあなたとエージェントハーネスが担います。

エージェントを接続する

インストーラーは Claude Code と Codex を自動的に接続します。Casefile プラグイン（スキルと、このインストールの MCP アドレスへの接続）をインストールし、OAuth でサインインします。トークンをコピーする必要はなく、どのファイルにも保存されません。サインイン用のターミナルがない場合、インストーラーはコマンドを表示します。それらを一度実行してください。

claude mcp login plugin:casefile:casefile
codex mcp login casefile

インストーラーは、他のプログラムに関する変更を加える前に確認を求めます。 プラグインの手順では、Casefile のものではないファイルを編集します。Claude Code の ~/.claude/settings.json（extraKnownMarketplaces.casefile 内の1行、"autoUpdate": true）、Codex の ~/.codex/config.toml、このインストールを参照する手動 MCP エントリー casefile と tracker、および ~/.agents/skills です。インストーラーはその一覧を表示し、ターミナルで [y/N] を尋ねます（curl … | sh の場合も同様です）。N を選ぶとプラグインの手順全体がスキップされ、これらのファイルには手を加えず、通常どおりサービスをインストールします。ファイルに初めて変更を加える前に、インストーラーはそのファイルの隣にコピーを保存します（settings.json.casefile-bak、config.toml.casefile-bak）。このコピーは保持され、上書きされません。必要な行だけを書き込み、ファイルの残りの部分はそのままにします。コピーにはファイルに保存されていた内容が含まれ、インストーラーが削除する手動エントリーのトークンも含まれます。不要になったら削除してください。これらの変数は sh の前に指定します。

• CASEFILE_SKILL=0 はプラグインの手順をスキップします。CASEFILE_SKILL=1 は質問への回答を事前に指定します。ターミナルがない場合（エージェント、CI）は質問されず、1 の場合と同様に手順が実行されます。
• CASEFILE_PLUGIN_AUTOUPDATE=0 は Claude Code プラグインを autoUpdate なしでインストールします。claude plugin update casefile@casefile を実行して、自分で更新してください。

ボードの Access 画面で接続を解除した後、エージェントに再度サインインさせる場合も、同じコマンドを使います（Claude Code のセッションでは、/mcp → casefile → Re-authenticate）。自分のマシンでは、サインインにパスワードは必要ありません。Claude Code は claude として、Codex は codex として動作します。

スキルはプラグインに含まれています。 接続するとエージェントにツールが提供されます。Casefile スキルは、それらの使い方をエージェントに教えます。インストーラーは Claude Code、Codex、Hermes、およびマシン上で見つかった他のエージェントにスキルを追加し、各ハーネスについて1行ずつ表示します。v0.8.0 より前にインストールした場合、スキルもプラグインもなく、1時間ごとの自動更新でも追加されません。自動更新されるのはサービスのみです。インストール行をもう一度実行するか、サービスには触れずにプラグインとスキルだけをインストールしてください（このマシン上にないサーバーの場合は、CASEFILE_URL=<address> を追加します）。

curl -fsSL https://raw.githubusercontent.com/azimov777/casefile/main/install.sh | CASEFILE_SKILL_ONLY=1 sh

エージェントがスキルを持っているか確認する方法と、各ハーネス用のコマンドについては、エージェントガイドのステップ4を参照してください。 Claude Desktop のチャットに拡張機能を追加できます。 Claude デスクトップアプリ（macOS、Windows）のチャットでは Claude Code プラグインは読み込まれません。代わりに、各リリースに添付されている casefile.mcpb から Casefile を追加します。インストーラーは Claude Desktop を検出すると、ファイルをダウンロードして開きます。手動でインストールする場合は、ファイルをダブルクリックしてください。OAuth でサインインするため、Node.js は不要で、インストール中も使用できます（詳細）。

Hermes は OAuth でサインインします（~/.hermes/config.yaml の auth: oauth。インストーラーが設定ブロックを出力します。実際の Hermes での確認はまだ行っていません）。OAuth を使わないクライアントには、エージェントキーを使います。 スクリプトや、MCP OAuth でサインインできないクライアントは、ヘッダーにエージェントキーを指定して、MCP アドレスのストリーム可能な HTTP 経由で接続します。インストーラーはそれぞれの設定ブロックにキーを出力します。~/casefile で docker compose run --rm --no-deps -T agent-token cat .secrets/agent-token を実行すると、キーを再度確認できます。mcpServers JSON を使うクライアントには、キーと、インストーラーが別のアドレスを出力している場合はそのアドレスを指定して、次の設定を使用します。

{
  "mcpServers": {
    "casefile": {
      "type": "http",
      "url": "http://localhost:8100/mcp",
      "headers": {
        "Authorization": "Bearer <token>"
      }
    }
  }
}

代替手段として、stdio 経由で接続できます。 上記のストリーム可能な HTTP が主な接続方法です。コマンドを起動して stdin/stdout 経由で通信する方法しか使えないクライアントには、同じサーバーを次の方法で接続できます。この方法では、インストール環境のデータベースに接続された、短時間だけ動作するコンテナーを起動します。使えるツール、キー、ケースは同じです。stdio 経由では OAuth を使用できません。エージェントキーはコマンドラインではなく、クライアントの環境変数に指定します。

claude mcp add --scope user casefile-stdio --env TRACKER_MCP_TOKEN=<token> -- \
  docker compose -f ~/casefile/docker-compose.prod.yml run --rm --no-deps -T \
  -e TRACKER_MCP_TOKEN mcp python -m app.mcp --stdio

stdio プロセス自体はデータベースを持たないため、インストール環境を起動しておく必要があります。クライアントのセッションごとに個別のプロセスが起動するため、クライアントが対応している場合は HTTP のほうが軽量です。stdio モードより古いインストールイメージでは、unrecognized arguments: --stdio と表示されます。まずイメージを更新してください。

ターミナルを使わずに、2つ目のエージェントを接続できます。 ボードの Connect an agent には、このインストール環境の MCP アドレスと、そのまま使える設定スニペットが表示されます。Access には、接続方法が3つのセクションに分けて一覧表示されます。エージェント接続（OAuth サインイン）、エージェントキー、サインインセッションです。管理者の場合は自分のものだけでなく、インストール環境全体のものが表示され、誰の代理であるか、誰が発行したか、最後に使用された日時を確認できます。接続はここで切断でき、キーは失効させられます。OAuth を使わないクライアントの場合は、ここでエージェントを登録し、そのエージェント専用のキーを発行して、キーがあらかじめ設定されたスニペットをコピーできます。キーは一度だけ表示されます。各エージェントに専用のサインインまたはキーを用意すると、そのエージェントのケース項目にはエージェント名が署名されます。共有インストール環境では、管理者でなくても各ユーザーが自分のエージェントを設定でき、発行した接続とキー、または自分の代理として登録されたものだけを確認できます。

実行内容を伝える

エージェントの接続は、あくまで準備です。接続したら、次の文を一言一句そのままエージェントに伝えてください。

引き継ぐ作業がありますか？ 次のように伝えてください。

この作業を Casefile にタスクとして登録してください。プロジェクトがまだなければ作成し、各タスクにはすべてのセクションと確認項目を含めてください。各タスクは1人のエージェントが一度に完了できる程度に小さくし、context には作業環境（作業場所と完了を確認する方法）を記載してください。作業そのものには着手しないでください。まだ作業内容を説明していない場合は、私に質問してください。

次に、新しいエージェントセッションで、次のように伝えてください。

Casefile トラッカーにある、この作業のタスクを実行してください。自分のコンテキストを節約するため、タスクをエージェントに割り当て、1人のエージェントにつき1タスクにしてください。対応できるタスクには、より安価なモデルを割り当ててください。

この2つの文は別々のエージェントセッションで使います。2つ目のエージェントはクリーンなコンテキストで開始し、タスクのケースに記載された内容だけを把握します。ボードの /start ページにも同じ文があり、コピーボタンからコピーできます。

ツール

サーバーが提供するすべての MCP ツールを、領域ごとに分類して掲載しています（app/mcp/tools/）。 タスク

• get_task — 1 回の呼び出しですべてのタスク情報を返します。カード、親タスクと子タスク、リンク、算出された機能、最新の要約、未解決の質問、未解決の所見、ディスカッション、ケースのインデックス、遷移先が含まれます
• search_tasks — クエリ言語の文字列、個別の条件、またはその両方でタスクを検索します
• create_task — プロジェクト内のエリアに backlog 状態のタスクを作成します（エリアが指定されていない場合は area_required）。必要に応じて親タスクの子として作成できます
• update_task — 指定されたタスクのフィールドを変更します。省略されたフィールドはそのまま維持されます
• transition — 固定の遷移表に従って、タスクを別のステータスに移します
• close_task — 1 回のトランザクションで、タスクをクローズします。エントリー、判定、最終要約を記録し、done に移します
• move_task — 理由を添えて、タスクまたはキーごとの結果を指定したタスクのリストを別のプロジェクトに移します。以前のキーから引き続きそのタスクにアクセスできます

ケース

• read_entries — 1 つのタスクのケースにあるエントリー本文を、ペイロードとともに番号順で返します
• add_summary — ケースの引き継ぎメモを 4 つのパートに分けた要約として記録します
• add_entry — ペイロードなしで、決定、試行、発見、成果物、所見、またはメモを記録します
• ask — ディスカッションでレジストリーの参加者に質問を記録します。タスクについて質問すると、同じ呼び出しでディスカッションを開始し、そのタスクを関連付けます
• answer — ディスカッションまたはタスクのケースにある質問に回答します。または、まだ回答されていない質問を、後続の質問によって withdrawn または replaced として理由を添えて終了します。回答済みの質問は撤回できません
• resolve — タスクに関する所見を解決し、結果と作業の移行先を記録します
• add_verdict — 1 件のレビュー確認の結果を記録します
• read_project_entries — プロジェクト、エリア、またはディスカッションのケースにあるエントリー本文を、ペイロードとともに番号順で返します。番号、種類、ステータス、タイトルまたは本文の部分文字列で絞り込めます
• add_project_entry — プロジェクトまたはエリアのケースに決定、発見、成果物、またはメモを記録します。または、ディスカッションのケースにメモを記録します

ディスカッション

• add_conclusion — ディスカッションの結論として、決定事項、置き換えられた事項、未解決の事項を記録します
• close_discussion — 1 回のトランザクションで、最終結論を添えてディスカッションを終了します
• list_discussions — プロジェクト、ステータス、ターン、関連付けられたタスクで絞り込んでディスカッションを一覧表示します。アドレス、タイトル、ステータス、ターン、未解決の質問、終了時刻が含まれます

ファイル

• request_file_upload — プロジェクトに新しいファイルをアップロードするための 1 回限りのリンクと curl -T コマンドを返します。バイトデータはディスクからトラッカーに直接送られ、モデルを経由しません
• request_file_replace — 同じ ID のファイルの内容を置き換えるための 1 回限りのリンクと curl -T コマンドを返します
• read_file — ファイルを返します。画像はモデルが認識できる image コンテンツとして、それ以外のファイルはカードと 1 回限りの curl -o リンクとして返します
• list_files — ファイルをカードとして一覧表示します。名前で検索でき、プロジェクトとメディアタイプで絞り込めます。追加または閲覧した時刻、サイズ、種類で並べ替えられます
• delete_file — ファイルのバイトデータを消去し、名前、種類、サイズ、削除者、削除日時を含む墓標を残します
• delete_files — 確認された件数が一致した場合、フィルターに一致するすべてのファイル（プロジェクト、名前、種類、指定日数の間に開かれていない画像を示す unopened）を消去します

リンク

• link — 2 つのタスクをリンクして両方のケースに link_added を記録するか、タスクをディスカッションに関連付けます
• unlink — リンクを削除して両方のケースに link_removed を記録するか、ディスカッションからタスクの関連付けを解除します プロジェクトと参加者
• get_project — キーを指定してプロジェクトを１つ、またはアドレスを指定してエリアを１つ、同じ形式で返します。形式には、キー、タイトル、説明、現在の属性値、有効な決定事項と調査結果、およびケースの残りのインデックスが含まれます。
• list_projects — エージェントが使用できるインストール済みプロジェクトの一覧を返します。キー、タイトル、アーカイブ日時が含まれます。アーカイブ済みのプロジェクトは、要求された場合にのみ含まれます。
• list_participants — 参加者レジストリ、つまり質問の宛先候補の一覧を返します。
• create_project — プロジェクトを作成します。
• update_project — プロジェクトのタイトルと説明を変更し、各変更をケースに記録します。
• archive_project — 理由を添えてプロジェクトをアーカイブし、プロジェクトとそのタスクへの変更を凍結します。
• restore_project — 理由を添えてアーカイブ済みのプロジェクトを復元します。
• set_attribute — 理由を添えてプロジェクト属性の値を設定します。属性がなければ作成し、既存の場合は値を変更します。履歴はプロジェクトのケースに残ります。
• remove_attribute — 理由を添えてプロジェクト属性を削除し、最後の値をプロジェクトのケースに記録します。
• register_participant — 人間または常駐エージェントを登録します。
• update_participant — 参加者の説明を変更します。

ジャーナル

• wait_journal — 指定したシーケンス番号より後のジャーナルエントリーを、新しいエントリーが届くまで待って返します。

日常的な操作

今すぐ更新する	インストール行をもう一度実行します
自動更新をオフにする	~/casefile/.env の CASEFILE_AUTO_UPDATE=false を設定し、~/casefile で docker compose up -d --no-deps updater を実行します
特定のリリースを使い続ける	~/casefile/.env の CASEFILE_VERSION=0.17.0 を設定します
停止／起動	~/casefile で docker compose stop ／ docker compose start を実行します
データを含むすべてを削除する	~/casefile で docker compose down -v を実行します
別のマシンまたは自分のサーバーに移行する	docs/moving.md
データをバックアップする／クリーンインストールに復元する	docs/backup-restore.md

ポートなどの設定は ~/casefile/.env にあります。詳しくは .env.example をご覧ください。

更新

Casefile の新バージョンは、バージョンの Git タグ vX.Y.Z と、そのイメージがバージョン名および stable チャネル名で ghcr.io に公開された時点でリリースとなります。すべてのインストールは、デフォルトで stable を追跡します。Docker の起動時に確認し、その後は毎時、時刻を少しランダムにずらして確認するため、リリースから約 1 時間 10 分以内にインストールへ反映され、再起動は不要です。タグのない main へのコミットがインストールに反映されることはありません。更新時には Casefile のコンテナが再作成され、データはボリュームに保持されます。その際に MCP 呼び出しの途中だったエージェントは接続が切れるため、再試行する必要があります。

アップデーターは Docker ソケットを使用します。 コンテナを置き換えるため、updater サービスは /var/run/docker.sock をマウントします。これはマシンへの root アクセスに相当します。Casefile がこの権限をこのサービスだけに意図的に与えている理由は、docker-compose.prod.yml に記載されています。インストーラーはインストール前と最後に、このことをお知らせします。自動更新を無効にするには、~/casefile/.env に CASEFILE_AUTO_UPDATE=false を設定し（値は厳密に false とします。それ以外の値では有効のままです）、~/casefile で docker compose up -d --no-deps updater を実行してください。サービスはその後アイドル状態になりますが、ソケットはマウントされたままです。docker compose stop updater を実行すると、次に docker compose up を実行するか、インストーラーを実行するまで停止します。自動更新を無効にすると、新しいリリースが公開されたときにボードで通知されます。サイドパネルの下部にリリースノートへのリンクが表示され、インストールコマンドをもう一度実行すると更新できます。この通知は GitHub で最新リリースを確認して表示され、確認は最大でも 1 時間に 1 回です。.env に TRACKER_RELEASE_CHECK=false を設定すると確認が無効になり、通知も表示されなくなります。

このチャネルでの最初のリリースは 0.2.0 でした。それ以前のインストール（latest を使用）は、次回の Docker 起動時に自動的に stable に切り替わり、その後は毎時確認するようになります。リリースに新しいアップデーターが含まれる場合もあります。そのリリースへの更新は引き続き旧アップデーターが実行し、その後、旧アップデーター自身が置き換えられます。そのため、新しいアップデーターが追加する機能（0.3.0 で追加された以下のロールバックなど）は、次のリリースからの更新に適用されます。.envでCASEFILE_VERSION=latest` を自分で設定している場合は、その行を削除してリリースを追跡してください。

CASEFILE_UPDATE_INTERVAL で確認間隔を設定できます（時間、または 30m。0 の場合は Docker の起動時のみ確認します）。リリースの起動に失敗した場合、インストールはその前に実行されていたバージョンに戻り、そのリリースを再試行しません。次のリリースは通常どおりインストールされます。何が起きたかは docker compose logs updater で確認できます。

データベーススキーマを変更するリリースでは、もう 1 つ手順が加わります。インストール前にアップデーターがデータベースのスナップショットを作成します（pg_dump -Fc。形式はバックアップと復元と同じです）。スナップショットはインストールの Docker ボリューム casefile_updater-snapshot に before-update.dump として保存され、手動バックアップと同程度の容量を使用します。スキーマを変更した後、そのリリースの起動に失敗すると、前のバージョンを再び起動する前にデータベースをスナップショットの状態に戻します。これにより、スキーマとデータは更新前の状態に正確に戻り、通常どおり手動で docker compose up -d を実行できます。その代わり、スナップショット作成からロールバックまでの間に書き込まれたデータはすべて失われます。 この期間は起動に失敗した場合に発生し、数分程度です。新しいバージョンの起動中も、数秒間は旧バージョンが応答し続けます。スナップショットは、更新に成功した場合もロールバックした場合も、その後削除されません。更新前のデータベースのコピーとしてボリュームに残り、保存場所は docker compose logs updater に表示されます。保存されるコピーは 1 つです。次にスキーマを変更する更新が行われると置き換えられます。また、スナップショットの作成に失敗した場合は、それ以前のスナップショットは置き換えられません。復元方法については、バックアップと復元を参照してください。スナップショットを作成できない場合、そのリリースは今回はインストールされません。復元できない場合、新しいスキーマ上で前のバージョンが実行され、スナップショットのコピー方法がログに記録されます。

ネットワークモード

デフォルトでは、Casefile は localhost でのみ待ち受けるため、入力する必要はありません。インストール時に管理者アカウント（owner@localhost）が作成され、ボードは自動的にそのアカウントでサインインします。他のマシンからアクセスするには、サインインを有効にしてください。すると、全員が自分のメールアドレスとパスワードでサインインし、各エントリーには作成者の署名が付きます。1 つのインストールにつきチームは 1 つで、サインインした全員がすべてのタスクを閲覧できます。役割は管理者フラグのみで、できるのはユーザーの管理だけです。

1. ~/casefile/.env に追加します。

   CASEFILE_LOGIN=password            # everyone signs in with email and password
   CASEFILE_BIND=0.0.0.0              # publish the board and MCP beyond localhost
   TRACKER_MCP_PUBLIC_URL=http://<server>:8100/mcp   # what agents on other machines use
   

2. ~/casefile で docker compose up -d を実行します。

3. 自分のパスワードを設定します。インストール時に作成された管理者アカウントにはパスワードがありません。次のコマンドで、一度だけ生成されたパスワードが表示されます。

   docker compose run --rm api python -m app.cli account-password --email owner@localhost
   

   --set-password を追加すると、自分でパスワードを入力できます（12 文字以上で、確認のため 2 回入力します。入力内容は表示されません）。メールアドレスも変更できます。 account-update --email owner@localhost --new-email [email protected]。

4. チームメンバーを追加します。ボード上で追加するか、サーバーで次を実行します。

   docker compose run --rm api python -m app.cli account-create --email [email protected] --name alice
   

   Alice のパスワードが一度だけ表示されるので、本人に伝えてください。--admin を指定すると、Alice も管理者になります。account-list で全員を確認できます。account-update --disable を実行すると、そのユーザーをロックアウトし、セッションと、そのユーザーがエージェント用に発行したすべての接続およびキーを無効にします（過去のエントリーには、引き続きそのユーザーの名前で署名が残ります）。account-password では、忘れたパスワードをリセットできます。Casefile はメールを送信しません。メールアドレスの確認も、パスワードリセット用リンクもありません。

ボードを http://<server>:8080 で開くと、サインイン画面が表示されます。エージェントは TLS 経由で OAuth を使ってサインインします（下記参照）。エージェントを接続には、TRACKER_MCP_PUBLIC_URL で指定したアドレスが表示されます。各ユーザーのエージェント用マシンでは、プラグイン、スキル、サインインを 1 行のコマンドでセットアップできます。Docker もサービスインストーラーも必要ありません。

curl -fsSL https://raw.githubusercontent.com/azimov777/casefile/main/install.sh | CASEFILE_SKILL_ONLY=1 CASEFILE_URL=https://mcp.casefile.example.com/mcp sh

エージェントのセットアップ手順については、 エージェントガイドを参照してください。

オーナーパスワードからの移行。 アカウント機能の導入前に TRACKER_PASSWORD_HASH でロックされていたインストール環境は、アップデート後も引き続き動作します。サインインは自動的に有効になり、以前のパスワードは管理者アカウント owner@localhost のパスワードになります。同じパスワードを使い、このメールアドレスでサインインしてください。.env のハッシュは、以後ロックとして機能しません。一度だけ移行に使われ、その後に設定したパスワードが上書きされることもありません。

平文 HTTP は危険です。 TLS を使わないと、パスワード、セッション Cookie、キー、エージェントのトークンがネットワーク上を平文で流れるため、通信経路上の誰もが読み取れます。Casefile 自体は TLS に対応していません。信頼できるネットワークの外部で使う場合は、CASEFILE_BIND=127.0.0.1 のままにして、両方のポートの手前に TLS 対応のリバースプロキシを配置してください。たとえば Caddy は証明書を取得し、X-Forwarded-Proto を自動的に送信します。

casefile.example.com {
    reverse_proxy 127.0.0.1:8080
}
mcp.casefile.example.com {
    reverse_proxy 127.0.0.1:8100
}

TRACKER_MCP_PUBLIC_URL=https://mcp.casefile.example.com/mcp を設定します。X-Forwarded-Proto: https を送信するプロキシを使うと、セッション Cookie に Secure が設定されます。

エージェントは OAuth でサインインします。 サインインが有効で、TRACKER_MCP_PUBLIC_URL が https の場合、MCP OAuth に対応したクライアント（Claude Code、Codex）にはアドレスだけが必要で、トークンは不要です。MCP ホスト上にページが開き、ユーザーはメールアドレスとパスワードでサインインし、クライアントがどのエージェントとして動作するかを選択します。デフォルトでは、そのユーザー自身のエージェントが選ばれます。これは初回サインイン時に作成されます。Alice の Claude Code はケースのエントリーに claude_alice と署名し、Codex は codex_alice と署名します（その他のクライアントでは agent_<name>）。一覧に表示されるのは、自分のエージェントと所有者のいないエージェントであり、他のユーザーのエージェントは表示されません。接続はそのユーザーが発行したものとして扱われます。ユーザー本人はアクセスで接続を確認して切断でき、管理者はすべての接続を確認できます。ユーザーのアカウントを無効にすると、そのユーザーが発行したすべての接続とキーが無効になります。エージェントのものも対象です。接続は自分で更新できないため、アカウントが復旧した後、改めてサインインする必要があります。OAuth に対応していないハーネスや、セッション間で実行されるジャーナルウォッチャーには、ユーザーがアクセスでエージェント用に発行したキーを使います。プロキシに必要な設定は次のとおりです。

• /mcp だけでなく、MCP ホスト全体をポート 8100 に転送してください。サインインでも、TRACKER_MCP_PUBLIC_URL に指定されたホストのルートにある /.well-known/…、/register、/authorize、/token、/oauth/… が使われます。
• クライアントの Host ヘッダーを維持してください。Caddy ではそのまま維持されますが、nginx では proxy_set_header Host $host; が必要です。サインインが有効な場合、MCP が応答するのは TRACKER_MCP_PUBLIC_URL のホストに対してのみで、別の名前でのリクエストには 421 が返されます。

localhost の外部で平文の http を使う場合、OAuth は一切ありません。エージェントは Access のキーを使って接続します。自分のマシン上（サインイン無効、ポートは localhost）では、エージェントはページを表示せずにすぐサインインします。Claude Code は claude、Codex は codex、その他のクライアントは agent として、それぞれ必要になったときに作成されます。

プロキシを指定してください。 サインインでは、アドレスによってパスワードを推測している人を見分けます（下の 推測 を参照）。プロキシ経由では、すべてのリクエストがプロキシから届くため、プロキシのアドレスをボードに知らせる必要があります。そうすると、ボードはプロキシの X-Forwarded-For からブラウザーのアドレスを取得します。それ以外の送信元からのこのヘッダーは無視されます。誰でも値を書き込めるためです。~/casefile/.env に次を追加してください。

CASEFILE_TRUSTED_PROXIES=172.18.0.1   # the address the board sees the proxy come from

次に docker compose up -d を実行します。このアドレスはプロキシ自体のものではなく、Docker がボードに表示するアドレスです。プロキシが同じマシン上にあり、CASEFILE_BIND=127.0.0.1 の場合、Linux と Docker Desktop のどちらでも、インストール環境のネットワークのゲートウェイになります。

docker network inspect casefile_default -f '{{range .IPAM.Config}}{{.Gateway}}{{end}}'

確認するには、docker compose logs ui を実行します。各リクエストの行は、リクエスト元のアドレスで始まります。プロキシを指定している場合はブラウザーのアドレス、指定していない場合はプロキシのアドレスです。複数のプロキシやネットワークは、カンマ区切りで指定します（172.18.0.1,10.0.0.0/8）。ネットワークのアドレスはネットワーク作成時に割り当てられるため、docker compose down の後はゲートウェイを再確認してください。プロキシの背後では CASEFILE_BIND=127.0.0.1 のままにしてください。Docker Desktop では、ネットワークに公開されたポートへのすべての接続が 192.168.65.1 として表示されるため、そのアドレスを指定すると、誰でも任意のアドレスを名乗れてしまいます。この行がなくても動作に問題はありませんが、プロキシの背後にいる全員が同じアドレスを共有するため、1 人がパスワードを推測しようとすると、全員が再び「しばらくしてからもう一度お試しください」と表示されます。

ほかに知っておくこと：

• サインインなしでは、ネットワークに公開できません。 CASEFILE_BIND が localhost の範囲外で、サインインが無効の場合、管理者キーをネットワーク全体に渡さないよう、ボードは起動を拒否します。理由は docker compose logs ui に表示されます。
• セッション。 サインインの有効期間は 7 日間です（TRACKER_SESSION_HOURS）。セッションは期限付きのトークンで、データベースに保存されます。インストール環境を再起動しても終了しません。サインアウトするとただちに無効になり、パスワードを変更またはリセットすると、そのユーザーのほかのセッションも終了します。アカウントを無効にすると、そのユーザーがエージェント用に発行したすべてのセッションと接続、キーが無効になります。再び有効にしても、いずれも復元されません。
• 推測。 間違ったパスワードは、アドレスごと、メールアドレスごとに、1 分間の範囲で数えられます。1 つのアドレスから 5 回間違えると、正しいパスワードを入力しても、1 分が経過するまでそのアドレスには「しばらくしてからもう一度お試しください」と返されます。1 つのメールアドレスに対して、どこからであっても 5 回間違えると、そのメールアドレスも同じように待機状態になります。それ以外のユーザーは通常どおりサインインできます。さらに、パスワードの推測によるプロセッサーの過負荷を防ぐため、インストール環境全体で 1 分間に許可される間違ったパスワードは最大 100 回です。複数のアドレスやメールアドレスに分散した推測がこの上限に達すると、推測が続く間、全員に「しばらくしてからもう一度お試しください」と表示されます（IPv6 クライアントは /64 全体として数えられます）。すでに開いているセッションや、トークンを使うエージェントには影響しません。クライアントのアドレスは、接続を開いたアドレスか、指定したプロキシが報告するアドレス（上記）です。Docker Desktop では、ネットワークからのすべての接続のアドレスが独自の 1 つのアドレスに隠されるため、同じマシン上のプロキシ経由でない限り、ボードはクライアントを区別できません。

内部の仕組み

Python 3.14 · FastAPI · PostgreSQL · ストリーム可能な HTTP 経由の MCP · React 19 · Vite · Tailwind。バックエンドはリポジトリのルートにあり、Web UI は ui/ にあります。Web UI は英語とロシア語に対応しており、エージェント向けのテキストは現在ロシア語です。設計上の決定事項はメンテナーのトラッカーで管理しているため、issue でお問い合わせください。

コントリビューション

issue とプルリクエストを歓迎します。CONTRIBUTING.md から始めてください。コミットには署名（git commit -s）が必要です。これはコードを提出する権利があることを証明するもので、CI で確認されます。

ライセンス

MIT

---

採用をお考えですか？ Casefile を開発しました。Anthropic または OpenAI での募集について、ぜひお知らせください。GitHub からご連絡いただけます。