Scout — what a machine actually uses

The registry knows what vendors say. Scout reports what a machine does: which AI tools are installed, which MCP servers are configured and where they point, which model-provider keys are present, and (optionally) which AI tools are running. Every finding maps onto the registry, so an organisation sees its AI supply chain as it is, not as a paste.

npx @openwake/scout                      # print what this machine uses
npx @openwake/scout --json               # machine-readable
npx @openwake/scout --processes          # include running AI tools (first token of the command line only)
npx @openwake/scout --identify           # keep hostname and user instead of a hash
OPENWAKE_API_KEY=ow_live_… npx @openwake/scout --post    # send to your organisation; see /dashboard/footprint

In this repository: pnpm scout -- --post.

The Agent: on a schedule, per machine

npx -y @openwake/agent enroll --key ow_live_… (in this repository: pnpm agent -- enroll --key …) stores the key privately, reports once, then installs a schedule: a LaunchAgent on macOS, a systemd user timer on Linux (cron when there is no user session), a Task Scheduler task on Windows. status shows where it reports and what the last run found; uninstall removes the schedule, the config, the state and the log. Reports are identified (hostname and user) unless enrolled with --hash-identity; running AI apps are included unless --no-processes. The footprint carries an agent field so the dashboard can tell a managed machine from a one-off scan.

The native agent: one binary per platform

For machines without Node, and for fleets: a single static openwake-agent for macOS (arm64, amd64), Linux (amd64, arm64) and Windows (amd64), under 7 MB, from https://openwake.ai/dl/agent/latest/ (a versioned copy lives at /dl/agent/v<version>/) with a SHA256SUMS beside it.

# macOS / Linux (per user; run with sudo for machine-wide) curl -fsSLo openwake-agent https://openwake.ai/dl/agent/latest/openwake-agent-darwin-arm64 && chmod +x openwake-agent ./openwake-agent enroll --key ow_live_… --every 6h

# Windows (PowerShell as Administrator for machine-wide) Invoke-WebRequest https://openwake.ai/dl/agent/latest/openwake-agent-windows-amd64.exe -OutFile openwake-agent.exe .\openwake-agent.exe enroll --key ow_live_… --every 6h

Elevated means machine-wide: the binary is installed to /usr/local/bin or C:\Program Files\Openwake, the config to /etc/openwake, /Library/Application Support/Openwake or C:\ProgramData\Openwake, the schedule is a LaunchDaemon, a systemd system timer or a Task Scheduler task running as SYSTEM, and the device is identified as the machine. Otherwise everything is per user. status shows where it reports and when it last ran; uninstall removes the schedule, the installed binary, the config, the state and the log.

The native agent adds one thing the Node agent does not: at each run it samples which remote hosts each process has open connections to (process name and host only, private addresses dropped) and reports them, so a vendor reached by a desktop app shows on the Footprint page as seen "via network". It updates itself only from GET /v1/agent/latest, a manifest signed by the Openwake release key (the public half is compiled in) with a SHA-256 per asset, a staged rollout percentage and a pause flag. A bad signature or hash is refused and logged. The design and the rules it follows are in business/agent-platform-2026-09.md.

What it reads

Source	What is kept
Tool config directories and binaries on PATH: Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, GitHub Copilot, Codex CLI, ChatGPT Desktop, Gemini CLI, aider, Continue, Zed, Ollama, LM Studio	the tool's name and the path or binary that proved it
MCP configs: `~/.claude.json` (incl. per-project servers), Claude Desktop, Cursor, Windsurf, VS Code `settings.json` / `mcp.json`, Codex `config.toml`, Gemini CLI, Continue, Zed	server name, transport, the package or host it points at, a vendor hint
Environment variable names such as `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `GEMINI_API_KEY`, `HF_TOKEN`	the name and the vendor it implies; values are never read
`--processes`: the process list	the first token of matching command lines, mapped to a tool

What it never does

No prompts, no conversation history, no file contents beyond the config files above, no secret values. Query strings are stripped from URLs; anything shaped like a token is replaced by [redacted] before it leaves the machine, and the API scrubs again on receipt. The device is identified by a hash of hostname and user unless --identify is given.

Server side

POST /v1/footprint (an org API key) validates the inventory, resolves every vendor hint against the registry (domain first, then name), records unmatched hints in the coverage queue by count only, stores the report, and appends a ledger entry. GET /v1/footprint returns the latest report per device and the vendors seen across them; GET /v1/org/landscape merges watched and seen vendors and computes concentration over what is underneath (hyperscalers, model providers). The dashboard shows all of it at /dashboard/footprint.