This file documents intentional behavior differences between upstream openusage and this repository (openusage-cli).
- Upstream
openusagebehavior:host.env.get(name)first checks the process environment, then falls back to launching shell commands (for exampleprintenvthrough login/interactive shell modes) to discover variables that are only present in user shell initialization. openusage-clibehavior:host.env.get(name)reads from the process environment only. It does not launch a shell and does not runprintenvfallback commands.
Upstream runs in desktop/Tauri contexts where the app process may not inherit the same environment as an interactive terminal session. Shell fallback helps plugins find variables configured in shell startup files.
openusage-cli is a daemon-first service. Launching shell startup logic during bootstrap/probe can cause operational problems:
- shell init can be slow and delay daemon startup;
- shell init can execute arbitrary user scripts with side effects;
- shell/job-control behavior can interfere with process lifecycle in interactive sessions.
For predictability and safety, openusage-cli treats the daemon process environment as the only source of truth.
- Upstream
openusagebehavior: the plugin API does not include a file subscription mechanism. Plugins read local files during each probe viactx.host.fs.*synchronous I/O, and no reactive refresh occurs on file changes. openusage-clibehavior: extends the plugin API withctx.host.fs.subscribeFile(path). Plugins can declare exact file dependencies. When a declared file changes, the daemon debounces changes and performs a targeted cache refresh for the affected providers only (no daemon restart). The monitor actor is independent of the static restart watcher.
For detailed documentation, see Provider file monitoring.
- Upstream
openusagebehavior: no account discovery mechanism exists. Each plugin runs one probe per refresh and produces a single result. openusage-clibehavior: extends the plugin API with an optionaldiscoverAccounts(ctx)export. When present, the runtime calls it to obtain an array of account descriptors, then probes each account sequentially with an inherited context containing an immutableaccountidentity. Override scripts can intercept, replace, wrap, or reset discovery viaglobalThis.__openusage_overridehelpers.
For detailed documentation, see Usage (multi-account discovery section) and Plugin Overrides.