mcpField
W
wyd

wyd

ローカル
wyd.sh開発ツール47 週間前に更新

wyd について

wydは、macOSとLinuxでコーディングエージェントを使う人向けのローカル実行状況追跡ツールです。開発プロセスをエージェントのセッションやプロジェクトに結び付け、残存プロセスの理由を示し、期限付きコマンドを監督できます。

主な機能

  1. 01プロセスをセッションやプロジェクトに関連付け
  2. 02根拠を示してプロセスの所有元を説明
  3. 03セッションと管理対象の実行を確認
  4. 04期限とログ付きでコマンドを監督
  5. 05MCP経由で読み取り専用の実行状況を提供

活用シーン

  1. 01プロセスを起動したエージェントセッションの特定
  2. 02残存するブラウザーや開発サーバーの確認
  3. 03タイムアウトと出力保存付きのテスト実行

MCP 対応

wydはstdio経由でMCPサーバーを提供します。クライアントはセッション、プロセスの所有元、実行、出力、容量を照会でき、実行の開始やキャンセルには`--allow-run`が必要です。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

インストール方法は未掲載です

このサーバーのパッケージやリモートエンドポイントはまだ取得できていません。プロジェクトの README の手順に従ってください。

リポジトリ
パッケージ
cargowyd0.10.0

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

wyd

wyd? — 何をしているの?

コーディングエージェントが起動したままにしているものを確認できます。

コーディングエージェントは、MCP サーバー、ヘッドレスブラウザー、開発サーバー、ワーカー、データベースを起動します。

ps で実行中のものは分かります。wyd ならその理由も分かります。どのセッションがどのプロジェクトで起動したのか、残されたものなのかを確認できます。

OpenCode
└─ chrome-devtools-mcp
   └─ Chromium ×8       1.2 GB

Agent exited 47m ago
⚠ leftover

ローカルで動作し、macOS と Linux に対応しています。アカウントもネットワークもテレメトリーも不要です。

https://wyd.sh

curl -fsSL https://wyd.sh/install.sh | sh
# or
brew install oxyplay/tap/wyd
# or
cargo install wyd
wyd
wyd upgrade   # brew or cargo, matching the install
wyd --demo    # deterministic synthetic dataset — screenshots/demos, no host scan

タグ付きリリースごとに crates.io にクレートを公開し、 oxyplay/homebrew-tap の Formula/wyd.rb を自動で更新するため、手動での作業なしに wyd upgrade を最新の状態に保てます。数式の更新が遅れている場合も、wyd upgrade はヒントを表示します。

バイナリー:GitHub Releases。クローンからインストールする場合:cargo install --path .

wyd TUI(wyd --demo)— 5 つのエージェントセッション、MCP サーバー、開発サーバー、データベース、Docker

OS デーモンは表示されません。デスクトップ版 Chrome も表示されません。エージェントが起動した Chromium は表示されます。

wyd を使う理由

ps / アクティビティモニターDocker Desktopwyd
すべてのプロセスはいコンテナーのみ開発用ランタイムのみ
起動したユーザーいいえCompose ラベルエージェント → MCP → ブラウザー
プロジェクトいいえ場合によるcwd / git ルート
残されたものかいいえ推測が必要理由とともにスコアを表示
安全な終了祈るしかありませんstop/rmPID + 起動時刻、確認には y
ボリューム—簡単に削除できる未使用 ≠ 不要なもの。削除には D が必要

コーディングエージェントを一日中実行し、その後「このセッションは何を残していったのか?」と尋ねる人のために作られています。

ランタイムの所有関係

ライブビューに加えて、wyd はコーディングエージェントのランタイムセッションを追跡します。セッションが起動したリソースを boot_id + pid + start_time をキーとして記録するため、プロセスの親が変更されたり Wyd が再起動したりしても、起動元を確認できます。完全な祖先関係が失われた場合は、説明可能なスコアを使って決定論的なリゾルバーがリソースをセッションに割り当てます。

  • TUI の最上位にある Sessions ビュー:エージェント · プロジェクト · 状態 · 経過時間 · ID と、詳細パネル。
  • wyd why <pid> — プロセスを所有するセッションと、その根拠を表示します。どのエージェントセッションにも所有されていない場合は、代わりにシステム上の起動元(systemd unit、launchd、cron、tmux、ssh、snap、flatpak、対話型シェル)と、祖先プロセスの一覧を表示します。終了コード:0 正常に所有されています、1 残存/帰属先なし、2 実行されていません、5 内部エラー。
  • wyd --json sessions — 記録されたセッションを JSON で表示します。
  • wyd serve — Unix ソケット(wyd.sock、モード 0600、単一インスタンス)を介したローカルデーモンです。起動元情報を最新の状態に保ち、読み取り専用の問い合わせに応答します。ベンダーは session_start / session_end でセッションを登録できます(ベンダー側の ID はエイリアスとして Wyd セッションに対応付けられます)。
  • wyd mcp — stdio 経由の Model Context Protocol サーバーです。コーディングエージェントは、セッション、PID の所有者、管理対象の実行について wyd に問い合わせることができます(--allow-run を指定すると、ホスト上での実行が可能になります)。

MCP

wyd は stdio 経由の Model Context Protocol にも対応しているため、コーディングエージェントは、このマシン上で自身やほかのエージェントが起動したままにしているものを確認できます。

wyd mcp                 # read-only
wyd mcp --allow-run     # also allows starting and cancelling runs

ローカル MCP サーバーを起動します。読み取りツールは常に利用できます: list_sessions(記録されたエージェントセッション)、explain(PID で指定したプロセスを所有するセッション)、list_runs、get_run、read_run_output、get_capacity。--allow-run を指定すると、その接続に限り start_run と cancel_run が追加されます。指定しない場合、これらの呼び出しは --allow-run を指定して再起動するようメッセージを表示して拒否されます。ネットワークもアカウントも不要です。回答はローカルの起動元情報ストアから取得されます。

MCP Registry に登録済み:

  • MCP Registry 名:mcp-name: io.github.oxyplay/wyd

管理対象の実行

wyd run はローカルのスーパーバイザーの下でコマンドを起動するため、エージェントはハングしたシェルではなく、期限、wyd が所有するプロセスグループ、サイズが制限されたログを利用できます。

wyd run --timeout 120s -- npm test

コマンドはシェルではなく argv です。&&、パイプ、グロブを使うには、明示的に sh -c を指定してください。--timeout のデフォルトは 10m、--grace(ソフト停止から強制停止まで)は 3s、--cwd には絶対パスを指定する必要があります。--json を指定すると、キャプチャした出力の代わりに 構造化された結果が出力されます。24 時間以内に同じ --request-id を再指定すると、 2 回目の実行を開始する代わりにその実行が再利用されます。同じ ID で異なるコマンドを指定すると拒否されます。

実行は共通の受付予算を使用するため、1 台のマシン上の複数のエージェントが一斉に 起動することはありません。wyd run は実行ごとにリソース要求を受け取ります。

wyd run --memory 512 --enforce monitored --queue-timeout 60s -- npm test
フラグ意味
--memory <MiB>実行予算に対して予約されます。--enforce monitored の場合は、停止しきい値にもなります。
--enforce none|monitored|hardデフォルトは none です。monitored は、観測された使用量が --memory を超えると実行を停止します。hard はカーネル制限であり、バックエンドが適用できない場合は起動前に拒否されます。暗黙に引き下げられることはありません。
--queue-timeout <dur>スロットを待機できる時間です。この実行では queue_timeout_secs を上書きします。--timeout とは別で、こちらは起動時にのみ計時が始まります。キュー内での待機が長すぎると、詳細にキュータイムアウトが記録されて timed_out で終了します。実行タイムアウトは消費しません。
--cpu <millicores>CPU 要求です。参考値であり、現時点でこれを適用するバックエンドはありません。
--processes <n>プロセス数の要求です。参考値であり、現時点でこれを適用するバックエンドはありません。

監視対象のメモリしきい値によって停止した実行は、outcome=resource_limit で終了し、 終了コードは 137 になります。limit_event には観測された数値が記録されます。

予約量は予算であり、実測 RAM ではありません。 reserved_memory_bytes は、 許可された実行が予約した量の合計です。実際の使用量ではありません。 実測使用量は別途 observed_memory_bytes として報告されます。macOS では、 200 ms ごとにサンプリングした、実行のプロセスグループ内の RSS の合計です。 共有ページが複数回カウントされることがあり、短時間のピークを見逃す可能性もあるため、 これは観測値であり、保証値ではありません。

macOS にはハードメモリ制限がありません。aggregate_memory_limit は monitored となり、--enforce hard は引き下げられるのではなく、実行作成前に拒否されます。 Linux のハード制限は委譲された cgroup v2 サブツリー(memory.max、memory.swap.max、cpu.max、pids.max)を使用するため、 利用可能な場合、aggregate_memory_limit、cpu_quota、process_limit は available と報告されます。 委譲されていない場合は unavailable と報告され、hard の要求は拒否されます。wyd が root 権限を求めることも、 systemd ユニットを書き換えることもありません。スーパーバイザーを Delegate=yes のユニットに配置するか、 所有する委譲済みサブツリー内のディレクトリを WYD_CGROUP_ROOT に指定して、 スーパーバイザーを再起動してください(機能は起動時に確定します)。cgroup メンバーシップは すべての子孫プロセスに継承されるため、プロセスグループから離脱する setsid の子プロセスも 実行の cgroup 内に残り、実行とともに強制終了されます。実行は、memory.max が実行予算に設定された 共通の集約 cgroup の下でも動作します。そのため、予算は受付ルールだけでなく、合計量に対する カーネル制限でもあります。wyd capacity --set memory_budget_mb=… でこれを更新できます。 [runs] に cpu_budget_millicores、pids_budget、またはその両方を設定すると、 すべての実行の CPU 合計とプロセス数を同様に制限できます(wyd capacity はこれらを報告し、 実行中の変更もカーネルに反映されます)。

実行後に内容を確認したり停止したりできます。

wyd runs                  # recent runs: state, outcome, cleanup, duration
wyd runs --json           # full RunView records
wyd logs <id> --follow    # retained stdout (--stream stderr for the other)
wyd cancel <id>           # idempotent

wyd capacity は受付上限と現在の使用量を表示します。--json を指定すると、 機能の状態(monitored、available、unavailable)も追加されます。

wyd capacity                                              # slots, queue, reservations
wyd capacity --json                                       # the full Capacity record, incl. capabilities
wyd capacity --set max_parallel=2 --set queue_timeout_secs=30

--set は繰り返し指定でき、任意の [runs] キーに対して key=value を指定します。

キーデフォルト意味
max_parallel4同時に許可される実行数です。
max_parallel_per_project2プロジェクトルートごとに同時に許可される実行数です。
max_queued32キューの長さです。上限を超えるリクエストはハングせず、拒否されます。
queue_timeout_secs600リクエストが実行枠を待機できる時間です。
memory_budget_mb8192実行中の実行によって予約できるメモリの合計です。
default_run_memory_mb512メモリ量が指定されていない実行に対する予約量です。
starvation_after_secs60この時間だけ後回しにされたリクエストは、次の実行枠を獲得します。

上限を変更すると、それ以降の実行許可に適用されます。実行中のタスクは 終了させません。すでに許可された実行数が新しい上限を超えている場合は、 その一時的な超過が隠されず、over_parallel_limit として報告されます。同じ キーは ~/.config/wyd/config.toml の [runs] セクションにもあります。

TUI では同じ実行を読み取り専用で表示します。Overview ペインで Runs を 選択し、enter を押すと実行の詳細が開きます。Runs ペインには設定済みの上限も 表示されます(TUI はスーパーバイザーソケットではなくストアを読み取るため、 ライブの件数は利用不可と表示されます)。また、キューに入っている実行については、 その位置、待ち時間、理由も表示されます。ウェブダッシュボードにも同じ表示に加えて ライブ容量パネルがあります。どちらも上限を変更したり、コマンドを開始したりする ことはできません。

実行を所有するのは、開始したクライアントではなくスーパーバイザーです。CLI または MCP 接続が切断されても、実行は期限まで継続し、その後も結果とログは残ります。 読み取りは永続化されており、デーモンも不要です。wyd runs、wyd logs、 MCP の list_runs/get_run/read_run_output はストアと保持されたログファイルを 読み取るため、スーパーバイザーが起動していなくても動作します。スーパーバイザーが 起動していないとき、wyd capacity とウェブダッシュボードの容量パネルは スーパーバイザーを起動せず、空のキューとともに設定済みの [runs] の上限を報告 します。一方、MCP の get_capacity ツールは start_run と同様に、スーパーバイザーへ 問い合わせ、必要に応じて起動します。実行の開始またはキャンセルにはスーパーバイザーが 必要です。スーパーバイザーは必要に応じて起動し、5 分間アイドル状態が続くと終了します。 次の wyd run または wyd mcp --allow-run で再び起動します。スーパーバイザーに SIGTERM/SIGINT が送られると、実行中のタスクは放置されず、先に停止されます (最大 10 秒)。

終了コード:コマンドが終了した場合はコマンド自身のコード、シグナルを受けた場合は 128+signal、タイムアウト時は 124、キャンセル時は 130、コマンドを起動でき なかった場合は 125、リソース上限によって停止された場合は 137 です。正確な理由は 常に JSON の outcome、exit_code、signal、cleanup、detail、 limit_event に記録されます。

出力はストリームごとに 10 MiB、保持される実行全体で 250 MiB に制限されます。 先頭部分が保持され、切り詰められたことが報告されます(JSON の stdout_truncated/stderr_truncated、wyd logs では stderr 上のマーカー)。 制限に達した後もパイプの読み取りは継続されるため、出力の多いテストによって スーパーバイザーが停止することはありません。終了した実行とそのログは 7 日間保持 されます。

これは何ではないか

管理対象の実行は、macOS と Linux 上のローカルプロセスであり、それ以上のものではありません。

  • クリーンアップの対象は、実行自身のプロセスグループです。コマンドがそこから離脱する場合 — setsid、二重フォーク、外部デーモンなど — 対象範囲内であるかのように 暗黙に扱うことはありません。cleanup は complete ではなく、 incomplete または unknown を報告します。
  • TMPDIR、TMP、TEMP は、実行専用のディレクトリを指します。これは 利便性のためのものであり、サンドボックスではありません。コマンドは引き続き、 書き込み権限のある任意の場所に書き込めます。
  • ファイルシステム、ネットワーク、シークレットの分離はなく、パッケージの インストールも制御しません。信頼できないコードはここではなく、コンテナまたは VM で 実行してください。
  • 監視対象のメモリ制限はポリシーであり、保証ではありません。200 ms ごとの サンプル間に発生した短時間のピークは見逃され、共有ページが二重にカウントされる こともあります。ハードメモリ、CPU、プロセス数の制限はバックエンドによって 異なります。macOS では監視のみを行い、Linux では利用可能な場合に委譲された cgroup v2 サブツリーを通じて制限を適用します。利用できない場合、機能は unavailable と報告され、hard リクエストは近似値で代用せず拒否されます。 macOS でハード制限を使うには、Linux 実行バックエンド(コンテナ/VM)が必要です。 それが実現するまでは、リソース制限付きのコマンドをコンテナで実行してください。 この機能と実際の一時停止/再開テストに関する計画の次のステップは、 docs/managed-runs-plan.md → «次にすべきこと» にあります。
  • 予約は予算であり、実測 RAM ではありません。reserved_memory_bytes は 実行が使用できる量を示し、observed_memory_bytes はある実行で使用が確認された量を示します。

MCP の設定:wyd mcp は読み取り専用です。wyd mcp --allow-run を指定すると、 その接続で start_run と cancel_run が有効になります。start_run は ホスト上での実行として説明されており、wyd によってサンドボックス化されることはありません。

WebMCP

ホスト型デモをお試しください:https://demo.wyd.sh

wyd は 11 個の WebMCP ツールを公開しており、ブラウザーエージェントは人間が見るものと 同じ UI で残存プロセスを調査できます。ツールは list_sessions、get_session、 list_leftovers、explain_process、focus_resource、propose_cleanup のほか、 管理対象実行の読み取り用ツール list_runs、get_run、read_run_output、 get_capacity、提案専用の propose_cancel_run です。ツール呼び出しによって プロセスが終了されることはありません。クリーンアップは人間が確認し、実行の キャンセルも同じ確認済みの提案を通じて行われます。Web から制限とキューの状態は 読み取れますが、制限の変更やコマンドの開始はできません。

wyd web         # local runtime (loopback)
wyd web --demo  # synthetic dataset, no host data
クイックテスト

これをブラウザーエージェントに貼り付けてください。デモ (またはローカルの wyd web)で試せます。

Find an ended OpenCode session, show me what it left running, explain Chromium PID 4102, and prepare a cleanup proposal. Do not execute cleanup.

WebMCP のサポートは、既存の wyd CLI/TUI ランタイムインスペクターを基盤として、 OpenAI WebMCP Challenge の期間中に追加されました。

docs/webmcp.md をご覧ください。

キー操作

キー操作
← → / h l概要/一覧
↑ ↓ / j k移動(詳細ポップアップをスクロール)
Tab概要/一覧にフォーカス
backspace戻る(フィルター/プロジェクト/セクションをクリア。終了はしません)
enter詳細ポップアップを表示。プロジェクト上では、そのプロジェクトをピン留め
space複数項目を選択
x / K終了/強制終了(y で確認)
s実行中の Docker コンテナを停止(実行中のものが先に並びます)
cDocker をクリーンアップ(y。ボリュームには D が必要)
P未使用の匿名ボリュームを削除(確認が必要。名前付きデータは保持)
o選択したリスナーを HTTP として開く(o try HTTP — 明示的な仮定です。リスナーは URL ではなくソケットとして表示されます)
pプロジェクト
/フィルター
r更新
?ヘルプ
escポップアップを閉じ、その後フィルター/プロジェクトをクリアし、最後に終了
q終了

終了シグナルの対象は、その項目自身の PID のみです(PID と開始時刻を再確認します)。 名前付きボリュームが不要データとして扱われることはありません。削除対象として提示されるのは、 確認付きで削除できる、アタッチされていない匿名ボリュームのみです(P)。 下部のヒント行は状況に応じて変わり、現在選択している行に適用できる操作を表示します。

スクリプト

TUI と同じスナップショットです。エージェントがタスクを完了した後に便利です。

wyd --json leftovers
wyd --plain mcp
wyd --json project myapp
wyd --json sessions      # recorded agent sessions
wyd why <pid>            # which session owns a process, and the evidence
wyd why <pid> --tree     # full ancestry tree: path + children, target marked
wyd ports                # listening ports: process on each + what started it
wyd ports --json         # same, machine-readable
wyd serve                # local daemon: Unix-socket API + keeps provenance fresh
wyd mcp                  # MCP server over stdio (for coding agents)
wyd prune --dry-run      # list anonymous volumes that would be deleted
wyd prune                # confirm, then delete them

フィルター:leftovers、mcp、agents、docker、project、sessions(JSON のみ)。

wyd why <pid> は、プロセスがアクティブなセッションに正しく所有されている場合は 0、残存プロセスであるか、記録された所有者がいない場合は 1(代わりにシステムの起動元が表示されます)、pid が実行されていない場合は 2、内部エラーの場合は 5 で終了します。そのため、スクリプトや CI では wyd why <pid> && … または case $? を使用できます。

wyd why <pid> --tree は、説明文の代わりに完全な祖先ツリーを出力します。pid 1(または表示可能な最上位の祖先)から対象プロセス(◀ で表示)までのパスと、対象プロセスの子プロセスが出力されます(最大 10 件。それを超える場合は … (+N more) の行が追加されます)。これは純粋な構造の表示であり、来歴情報は必要ありません。

wyd ports は、すべてのリスニングソケットを address:port 形式で一覧表示し、それを使用するプロセスと起動元も表示します。来歴情報から判明する場合は所有するエージェントセッション(session opencode (active))、判明しない場合はシステムの起動元(systemd (postgresql.service)、launchd、cron、…)が表示されます。--json は各エントリーについて {address, port, pid, process, owner_agent, owner_session, owner_state, source} を返し、該当しないフィールドは省略します。

{
  "runtime": [{ "type": "mcp", "name": "chrome-devtools-mcp", "pid": 94148, "status": "leftover", "reasons": ["owning agent missing"] }],
  "docker": [{ "type": "dangling-image", "name": "abcdef012345", "status": "dangling", "size_bytes": 1400000000 }]
}

フィールド名はメジャーバージョンが上がるまで変更されません。空の ports / reasons / children / project は省略されます。

設定

~/.config/wyd/config.toml — ファイルがなくても問題ありません。

[leftovers]
server_age_hours = 8

[runs]
max_parallel = 4
max_parallel_per_project = 2
max_queued = 32
queue_timeout_secs = 600
memory_budget_mb = 8192
default_run_memory_mb = 512
starvation_after_secs = 60

[persistent]
commands = ["postgres", "redis-server"]

[projects]
roots = ["~/Work"]

[keys]
quit = "q"
kill = "x"
force_kill = "K"
clean = "c"
stop = "s"
prune = "P"
help = "?"
refresh = "r"

[[signature]]
category = "agent"
names = ["myagent"]
contains = ["my-company-agent"]
display = "myagent"

ライセンス

Apache-2.0。Copyright 2026 Maksym Nevinchanyy。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。