vx info

vx info prints one screen of facts about the workspace and this machine, for bug reports and sanity checks. The task count and the sandbox row’s declared count come from the same load a run uses: the lock, plugin stages included. vx info evaluates no config; with no lock, or one a run would refuse, both counts are zero and projects lock says no — a broken config is vx lock’s to report.

Usage

vx info [--format pretty|json] [--cache-dir <path>]

Example

$ vx info

─ vx info ────────────────────────────────────────────────────
  vx                0.0.0
  bun               1.4.2
  git               2.53.0
  git status cache  core.fsmonitor, core.untrackedCache off
  workspace root    /work/repo
  projects          12 (34 tasks)
  plugins           2 — @vzn/vx-reapi (executor, cache); @vzn/vx-otel (telemetry)
  workers           2 — cgroup CPU quota 2 of 8 cores
  memory            13 GB usable — cgroup limit; the machine has 16 GB
  cache dir         /work/repo/.vx/cache (8.2 MB, this workspace's run history)
  cache store       /home/me/.vx/3f2a9c1e7b4d5a60/cache (1.3 GB, shared by this repo's checkouts)
  cache versions    keys vx-cache-v48 · index schema v49
  cache entries     42 (1.3 GB)
  orphans           3 artifacts (12 MB) the index does not know — `vx cache clean` reaps them
  task runs (24h)   7 (5 cache hits)
  flaky tasks       1 — web#test (3 of 11 runs failed on unchanged inputs)
  sandbox           available (9 tasks declare exec.sandbox)
  projects lock     yes

Options

Option	Meaning
`--format pretty\|json`	`json` prints the same facts as one typed object, below
`--cache-dir <path>`	read the cache a run with the same flag uses

Understanding the output

git shows (not found) when the binary is missing.
git status cache: vx runs ONE git status per run to find dirty and untracked files, and on a large tree that walk is the warm run’s critical path. git’s core.fsmonitor (a daemon that watches the worktree) and core.untrackedCache make it near-free after the first run; both are off by default, so vx info says when they are.
sandbox is the runtime probe’s verdict for THIS host — one sandboxed true, memoized — and how many loaded tasks declare exec.sandbox. A declared sandbox whose runtime cannot start fails the task at run time rather than downgrading, so unavailable — <why>; 3 tasks declare exec.sandbox and will fail says it first: root inside a container (the runtime’s seccomp helper cannot create its nested user namespace; run as a non-root user or set sandbox.weakerWhenNested: true), a missing bubblewrap, socat or ripgrep, a nested seatbelt on macOS. On Linux an available sandbox that cannot report the reads it denies (no strace on PATH, one whose --version fails, or one that may not attach) adds , untraced — <why>, so the reads it denies go unreported: the sandbox still enforces, but a task that tolerates a denied read passes and caches with no word of it. The --format json fact is sandbox.untraced, the reason or null.
plugins names every plugin .vx/workspace.* declares and the seams each fills, in pipeline order (config, discover, project, graph, key, fingerprint, schedule, admit, executor, cache, telemetry, output, setup, commands), or none. It reads the declarations: a plugin that declines a task at run time still lists its seam here.
workers is the count a run defaults to and where it comes from: .vx/workspace.ts’s run.concurrency when set, else the cores this process may use — the CPU count, capped by the cgroup CPU quota a container runs under (8 — the CPU count, 2 — cgroup CPU quota 2 of 8 cores). memory is what a memory-packing policy budgets (@vzn/vx-history): the machine’s total, capped by the cgroup limit — inside a container the raw numbers are the host’s, and the doctor is where to see which one a run reads.
flaky tasks is the standing list a run’s flaky notes add to: every task whose history (30 days, what the cache keeps) holds a cache key that failed after it had passed, most failures first, with the outcomes over those keys. A cache hit counts as a pass (it replayed one), and a pass that took a retry counts too, its failed attempts counted as failures. A task with no cache block keys on its config alone, so its key says nothing about its inputs: it is never listed. A pass or a failure behind a failed dependency, in a run that continues past failures, is not its key’s and counts on no key. none when no key did.
task runs (24h) counts task runs, executed and replayed alike, so the hits are a share of it: three vx run of two tasks are six. An invocation is what vx last calls a run; vx last --list counts those.
cache dir holds the index and this workspace’s run history; its size is on disk. cache store is where the entries and their artifacts live: the store shared by this repo’s checkouts (docs/caching.md), with its size on disk, or none: the cache dir holds the entries when the workspace names its cache dir. Before a first run it is the store a run would open. A bare vx cache clean frees both sizes.
cache entries counts the entries and their size. Paths under the home directory print as ~/…; the JSON keeps them absolute.
cache policy is the policy a vx run takes when no flag names one, and where it comes from (VX_CACHE_POLICY, .vx/workspace’s cache.policy, or the default, every layer on, remote writes off off CI); cache scope is VX_CACHE_SCOPE’s, or none: a run then takes a plugin’s (github()), else the branch’s from git.
cache versions are the two constants a bug report needs and the reset notice names: the key prefix (CACHE_VERSION; a bump orphans every entry) and the index schema (SCHEMA_VERSION; a mismatch drops every table on the next open, which the run then says once).
orphans appears only when the cache directory holds artifacts or save temps the index has no row for, older than an hour (what a SCHEMA_VERSION reset leaves behind; a fresh one is a save in flight). A task that asks for one’s key again indexes it and hits; the rest only vx cache clean reclaims, so the doctor says so.

JSON

--format json prints the same facts as one typed object, for a script or a bug-report template: vx, vxPath (the file that ran), handedOffFrom (the vx that handed the call to the project’s own, else null), bun, bunSupported (false below Bun 1.4.4), git (null when not found), gitStatusCache ({ fsmonitor, untrackedCache }, null when git could not answer), workspaceRoot, projects, tasks, plugins ([{ name, seams }]), workers ({ count, source, cores, cpuQuota }, the source one of workspace / cgroup / cores, cpuQuota in cores or null), memory ({ usableBytes, totalBytes, cgroupLimitBytes }, the limit null when none binds), cacheDir, cacheDirBytes (on disk: the index and run history), cacheStore (null when the cache dir holds the entries), cacheStoreBytes (on disk, null with no store), cacheVersion, schemaVersion, cacheEntries, cacheBytes, settings (every setting by path, { value, source }, source one of env / workspace / default, value null for the default), orphans ({ artifacts, bytes }, always present), runs24h, hits24h (task runs, as the row), restored24h (of those hits, the ones that restored outputs; the rest found them up to date), flakyTasks ([{ taskId, project, task, keys, passes, failures }], empty when none), lockfile, sandbox ({ available, reason, declared, untraced }, declared the count of tasks with exec.sandbox, untraced the reason denied reads go unreported or null). The pretty rows render this object; there is no second source.

Exit codes

Code	When
`0`	the facts printed, with no lock included
`1`	no workspace here or above, or a parse error

Turborepo, Nx and other product names are trademarks of their owners. vx is not affiliated with or endorsed by them.