wyd

wyd

wyd? — *what you doing?*

See what your coding agents left running.

Coding agents spawn MCP servers, headless browsers, dev servers, workers, and databases.

ps tells you what is running. wyd tells you why — which session started it, in which project, and whether it's leftover.

OpenCode

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

Agent exited 47m ago ⚠ leftover

Local, macOS and Linux. No account, no network, no telemetry.

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

Each tagged release publishes the crate to crates.io and bumps Formula/wyd.rb in oxyplay/homebrew-tap automatically, so wyd upgrade stays current with no manual step. wyd upgrade still prints a hint if a formula bump is ever lagging.

Binaries: GitHub Releases. From a clone: cargo install --path .

OS daemons stay hidden. Desktop Chrome stays hidden. Agent-spawned Chromium does not.

Why wyd

Built for people who run coding agents all day and then ask *what did that session leave behind?*

Runtime ownership

Beyond the live view, wyd tracks coding-agent runtime sessions — which resources a session spawned, keyed by boot_id + pid + start_time, so the provenance survives process re-parenting and Wyd restarts. A deterministic resolver attributes resources to a session with an explainable score when exact ancestry is gone.

• Sessions view in the TUI (top-level): agent · project · state · age · id, with a details panel.
• `wyd why ` — which session owns a process, and the evidence. When no agent session owns it, it names the system source instead (systemd unit, launchd, cron, tmux, ssh, snap, flatpak, or an interactive shell), with the ancestry chain. Exit codes: 0 cleanly owned, 1 leftover/unattributed, 2 not running, 5 internal error.
• `wyd --json sessions` — recorded sessions as JSON.
• `wyd serve` — a local daemon over a Unix socket (wyd.sock, mode 0600, single-instance). Keeps provenance fresh and answers read-only queries; vendors can register sessions with session_start / session_end (their id maps to a Wyd session as an alias).
• `wyd mcp` — a Model Context Protocol server over stdio, so a coding agent can ask wyd for its sessions, who owns a PID, and its managed runs (--allow-run adds host execution).

MCP

wyd also speaks the Model Context Protocol over stdio, so a coding agent can ask the machine what it — or other agents — left running.

wyd mcp                 # read-only

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

Starts the local MCP server. Read tools are always available: list_sessions (recorded agent sessions), explain (which session owns a process, by pid), list_runs, get_run, read_run_output and get_capacity. --allow-run adds start_run and cancel_run for that connection only — without it those calls are rejected with a message to restart with --allow-run. No network, no account — the answers come from the local provenance store.

Registered in the MCP Registry:

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

Managed runs

wyd run starts a command under a local supervisor, so an agent gets a deadline, a process group wyd owns, and bounded logs instead of a hung shell.

wyd run --timeout 120s -- npm test

The command is argv, not a shell — &&, pipes and globs need an explicit sh -c. --timeout defaults to 10m, --grace (soft-to-forced stop) to 3s, and --cwd must be absolute. --json prints the structured result instead of the captured output; repeating a --request-id within 24 hours reuses that run instead of starting a second one, and the same id with a different command is rejected.

Runs share one admission budget, so several agents on one machine do not all start at once. wyd run takes a per-run resource request:

wyd run --memory 512 --enforce monitored --queue-timeout 60s -- npm test

A run stopped by a monitored memory threshold ends outcome=resource_limit and exits 137, with a limit_event naming the observed number.

Reservations are a budget, not measured RAM. reserved_memory_bytes is the sum of what admitted runs reserved; it is not what they are using. Measured usage is reported separately as observed_memory_bytes, which on macOS is the sum of RSS over the run's process group sampled every 200 ms. Shared pages can be counted more than once and a brief peak can be missed, so it is an observation, not a guarantee.

On macOS there is no hard memory limit: aggregate_memory_limit is monitored, and --enforce hard is refused before the run is created rather than downgraded. On Linux hard limits come from a delegated cgroup v2 subtree (memory.max, memory.swap.max, cpu.max, pids.max), so aggregate_memory_limit, cpu_quota and process_limit report available when one exists. Without delegation they report unavailable and a hard request is refused — wyd never asks for root and never rewrites your systemd units. Put the supervisor in a unit with Delegate=yes, or point WYD_CGROUP_ROOT at a directory you own inside a delegated subtree, and restart the supervisor (capabilities are fixed at its start). Because cgroup membership is inherited by every descendant, a setsid child that escapes the process group is still inside the run's cgroup and is killed with it. Runs also live under one aggregate cgroup whose memory.max is the run budget, so the budget is a kernel cap on the total and not only an admission rule; wyd capacity --set memory_budget_mb=… updates it. Set cpu_budget_millicores and/or pids_budget in [runs] to cap the total CPU and process count of all runs the same way (wyd capacity reports them, and a change at runtime updates the kernel too).

Inspect or stop it afterwards:

wyd runs                  # recent runs: state, outcome, cleanup, duration

wyd runs --json # full RunView records wyd logs --follow # retained stdout (--stream stderr for the other) wyd cancel # idempotent

wyd capacity shows the admission limits and what is in use; --json adds the capability states (monitored vs available vs 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 is repeatable and takes key=value for any [runs] key:

Changing a limit governs admission from then on; active runs are not killed for it. When the new cap is lower than the number of runs already admitted, the temporary exceedance is reported as over_parallel_limit instead of hidden. The same keys live under [runs] in ~/.config/wyd/config.toml.

The TUI shows the same runs read-only: select Runs in the Overview pane, enter opens a run's details. The Runs pane also shows the configured limits (live counts are marked unavailable there, because the TUI reads the store, not the supervisor socket) and, for a queued run, its position, wait and reason. The web dashboard has the same view plus a live capacity panel; neither can change a limit or start a command.

The supervisor owns the run, not the client that started it: if the CLI or MCP connection drops, the run continues to its deadline and its result and logs are still there afterwards. Reads are durable and daemon-free — wyd runs, wyd logs and the MCP list_runs/get_run/read_run_output read the store and the retained log files, so they work with no supervisor alive. wyd capacity and the web dashboard's capacity panel report the configured [runs] limits with an empty queue when no supervisor is running, instead of starting one; the MCP get_capacity tool asks the supervisor and starts it on demand, like start_run. Starting or cancelling a run needs the supervisor, which starts on demand and exits after five idle minutes; the next wyd run or wyd mcp --allow-run brings it back. SIGTERM/SIGINT to the supervisor stops its active runs first (up to 10s) instead of abandoning them.

Exit codes: the command's own code when it exits, 128+signal when it is signaled, 124 on timeout, 130 on cancel, 125 when the command could not be spawned, 137 when a resource limit stopped it. The precise reason is always in the JSON (outcome, exit_code, signal, cleanup, detail, limit_event).

Output is bounded per stream at 10 MiB and at 250 MiB total across retained runs — the head is kept and truncation is reported (stdout_truncated/stderr_truncated in JSON, a marker on stderr from wyd logs). The pipe keeps draining after the limit so a chatty test cannot wedge the supervisor. Finished runs and their logs are kept 7 days.

What this is not

Managed runs are local processes on macOS and Linux and nothing more:

• Cleanup covers the run's own process group. A command that leaves it — setsid, double fork, an external daemon — is not silently claimed as covered: cleanup reports incomplete or unknown instead of complete.
• TMPDIR, TMP and TEMP point at a run-owned directory. That is convenience, not a sandbox: the command can still write anywhere you can.
• No filesystem, network or secret isolation, and no control over package installs. Run untrusted code in a container or VM, not here.
• A monitored memory limit is a policy, not a guarantee: a brief peak between two 200 ms samples is missed, and shared pages can be counted twice. Hard memory, CPU and process-count limits depend on the backend: macOS only