Should CLI tools declare their network behavior before they run?

As a Linux maintainer, I’m uneasy when a CLI quietly turns a local command into a hosted data-sharing workflow. Crash reports, stack traces, dependency metadata, and usage telemetry can all be useful for debugging, security, and team collaboration—but the boundary should not be hidden behind a default install.

I’d like CLI tools and SDKs to ship a machine-readable network-behavior manifest: endpoints, payload categories, retention, and opt-out controls. VS Code already exposes structured telemetry metadata and can generate a JSON report of possible events, but there is no broadly adopted equivalent for command-line tools. OpenTelemetry helps describe exporters, not necessarily application retention or universal opt-out semantics.

I’m less certain about failing closed when the manifest is missing. That is safe, but could break useful tools; an explicit warning or package-manager gate may be more workable. Should this be a voluntary convention, a package-manager requirement, or enforced by operating systems and enterprise policies?

The distinction between “metadata exists” and “metadata is sufficient” matters. A structured telemetry report is useful evidence, but it does not establish retention or every extension’s behavior. I’d support a narrow manifest standard first, with explicit unknowns rather than a checkbox claiming completeness.

I’d make the manifest mandatory for distribution, not execution. Missing disclosure should produce a visible warning and an audit event, while a locked-down environment can choose to deny the tool. That separates user autonomy from enterprise policy instead of pretending one default fits both.

The hard part is payload classification. “Source code” is obvious; stack traces can contain secrets, file paths, tokens, and request data. A useful manifest needs categories granular enough to review, but not so complicated that nobody reads it.

If the manifest becomes a long legal document encoded as JSON, users will ignore it. Give me a stable schema and a compact human summary. The winning convention is the one that survives an install script and a security review, not the one with the most fields.

Fail-closed is the right policy for high-risk environments, but I would not make it universal. A missing manifest should mean “unknown,” not “safe.” Let package managers and enterprise controls enforce the stricter interpretation where the threat model requires it.

I’d also want offline behavior documented. If a command can complete locally but contacts an API for convenience, that distinction belongs beside the endpoint list. Otherwise the user cannot tell whether the network is essential, optional, or merely the vendor’s preferred workflow.

Procurement will understand this immediately if the manifest is machine-readable and versioned. Enterprises already need policy hooks for approved endpoints and data classes. “The vendor says it is telemetry” is not a control plane.

Package metadata tells me what a project claims to need. Maintainer scripts remind me that installation itself can do more than that. I’m in favor of disclosure, though I reserve the right to dislike another standard that only three tools implement.

The existing examples suggest a useful precedent, not a finished standard. Structured classifications and endpoint categories are a good start; retention and opt-out need separate, explicit fields. I’d avoid calling an exporter specification a privacy contract.

Please include the control’s scope. A core CLI setting may not govern plugins or extensions, and an organization-wide setting may override a user choice. “Opt out available” is too vague unless the manifest says who can change it and where.

There is a cost to fail-closed defaults: emergency tooling often runs before its metadata ecosystem is mature. I’d prefer fail-closed for silent collection, not for all network access. The tool can ask for explicit consent when its declared behavior is unavailable.

As a small developer, I could implement a manifest tomorrow; getting every dependency and plugin to provide trustworthy ones is another matter. Still, a standard gives users something concrete to request. “Trust us” is not an interface.

The disclosure should appear at the moment of consequence: install, first network call, or settings change. A file buried in a repository is technically available but socially invisible. Good defaults need good timing, not just good schemas.

I’d start voluntary, then let package managers reward or require it for selected trust tiers. Immediate OS enforcement sounds expensive and blunt. If adoption stalls, enterprise policy can create the pressure without making every hobby CLI pass a regulatory checkpoint.