v2.1.0

[2.1.0] - 2026-09-26

Added

• Copilot CLI is governed. vaara init writes ~/.copilot/hooks/vaara.json (under $COPILOT_HOME when set) with a preToolUse hook behind the fail-closed gate, since Copilot CLI runs a call whose hook outlives its timeout, and a post-tool hook for postToolUse and postToolUseFailure. Its bash, create, edit, view, skill and task calls are checked against the deny rules as Bash, Write, Edit, Read, Skill and Task, with paths resolved against the call's working directory, and the LLM proxy's tool gate translates the same names. The harness rules cover ~/.copilot/hooks/, config.json, settings.json and mcp-config.json under ~/.copilot, and a repository's .github/hooks/ and .github/copilot/. vaara scan and vaara init report Copilot CLI, and vaara ungovern removes the hook file. A CI job runs Copilot CLI 1.0.88 against a scripted model through its own bring-your-own-model settings, offline and signed out. Allowed and denied calls, four calls in one model turn, and attempts to delete the trail, delete its rows, read the signing key or delete the hook file are each decided and recorded, and a call whose engine crashed, is missing or hangs is refused.
• Linux OS layer. vaara run <agent> starts an agent, with or without a Vaara adapter, confined by the vaara-agent AppArmor profile and in a cgroup of its own, and everything the agent starts inherits both. The profile is the floor: no process in the agent's tree changes Vaara's trail, keys and settings, a harness's hook files, or the files a login shell, systemd, cron, SSH and git start from, including through sudo, and the kernel holds it whether or not the guard runs. The harness process keeps write access to its own settings files; the programs it starts do not.
• sudo vaara os-guard loads the profile and decides each open and exec an agent makes in the folders the operator picks. A record folder lets it through and records the first open of each file per launch. An ask folder holds it for a signed approval and refuses it at the timeout. A block folder is part of the floor. The guard writes each decision, each launch and each refusal the kernel reports for the profile to its own trail, /var/lib/vaara/os-layer/audit.db, which the operator's group can read and no process in an agent's tree can open. vaara run refuses to start an agent when the guard is not running or AppArmor is not enabled, and ends the agent when the guard stops.
• vaara os-layer and a panel in vaara dashboard pick folders and apps, show the guard and answer its questions. An attached app is governed by its path however it is started.
• Limits: a delete, rename or hard link raises no event the guard can decide, so in an ask or record folder it happens undecided; a hard link from outside into such a folder is refused. A Vaara adapter's hook runs inside the agent's tree and cannot open ~/.vaara there, so a harness with a Vaara adapter blocks its own tool calls under vaara run; start such a harness without vaara run, or without the adapter. AppArmor distributions only (Ubuntu, Debian, SUSE).
• The os-layer-e2e CI job runs the guard under sudo and Copilot CLI with no adapter under vaara run, against a scripted model, and checks the files and the guard's trail.

Fixed

• vaaraio/vaara@v1 ran the action as it stood at 1.66.2. The 1.66.2 entry said the floating v1 tag moves with each release, and no step moved it. The release job now moves v<major> to each full release of that major, and the container build runs only for full version tags, so moving the major tag does not re-push the image. tests/test_floating_major_tag.py holds both.