Vectis 0.2.0

Vectis 0.2.0

Read job logs, see why a repository is not ready, decide who can start runners on your Mac, and rerun, cancel or dispatch GitHub runs from every surface. Linux guests can run x86_64 tools through Rosetta, Windows guests are kept off your local network, and runners that hang or lose their job clean up after themselves.

Installed apps find this release within four hours, and the update waits for active work to finish. Read Before you update first: Linux environments need to be prepared again, and run control needs an updated GitHub App permission.

Before you update

• Prepare Linux environments again. Each Linux instance now gets its own SSH host key. Images prepared with 0.1.x report action_required until they are prepared again. To keep the environment ID, its vectis-<id> runner label and existing repository connections, remove the old environment and prepare the new image under the same ID. Removing an environment keeps its image files on disk.
• Approve the GitHub App's Actions write permission to use run control. Until then, rerun, cancel and dispatch report github_app_permission_required. Everything else works without it.
• Windows: rebuild QEMU with both Vectis patches. Windows guests now start only with a QEMU build that supports network isolation (native/qemu/patches/0002-isolate-vectis-user-network.patch). Existing Windows base images do not need reinstalling.

Highlights

Job logs on every surface

Read a GitHub job's log from the desktop, vectis job logs <job-id> --binding <id> [--follow], or the MCP tool vectis_job_logs. Logs are fetched on demand with a byte cursor, so following a running job only transfers new output. The desktop opens a log panel under each job with follow, wrap and copy.

Readiness checks with the next step

vectis repository readiness, the MCP tool vectis_readiness and the desktop's connect dialog check everything a repository needs, one item at a time: cloud connection, linked GitHub account, App installation, administrator access, fork approval policy, environment and connection. Each problem carries a code and the next step, and the desktop jumps to the place where you fix it. vectis doctor reports coded checks for the host runtime too. A new onboarding checklist on the Overview walks a fresh Mac from environment to first job.

Decide who can start runners on your Mac

Each repository connection now has an access policy: anyone who can run workflows, or only listed GitHub users, and automatic or manually approved capacity. Jobs from other actors never get a runner, and jobs that need approval wait in Needs you until you approve them. Because GitHub can hand a runner a different queued job than the one it was started for, a job-started hook inside the guest checks the assigned job against the policy before any step runs, and stops the runner if it does not match.

Rerun, cancel and dispatch

vectis run rerun-failed, vectis run cancel and vectis workflow dispatch, their MCP commands, and the job menu in the desktop control GitHub runs directly. Every request is idempotent: Vectis records it before contacting GitHub, never resends a request whose outcome is unknown, and reports such outcomes as unconfirmed instead of guessing.

x86_64 Linux tools through Rosetta

Opt in per Linux environment with vectis environment configure <id> --x64 rosetta. The guest then runs x86_64 binaries and docker run --platform linux/amd64 images through Apple's Rosetta, shared read-only into the guest. The runner stays ARM64 and keeps its labels, so workflows choose this explicitly.

Network egress for Windows guests

Windows guests are limited to the internet by default: connections to the Mac, its local network, loopback and link-local addresses are refused, while DNS and internet traffic work. Linux and macOS guests report their egress as not enforced on every surface, because Apple Virtualization's NAT cannot restrict it yet.

Runners clean up after themselves

• A runner requested for a job that no longer needs it is released after 10 minutes of inactivity, reported as runner_idle.
• An automatic runner request that a Mac never picks up expires after 2 minutes if the Mac went offline, or 10 minutes if it stayed online, so another connected Mac can take the job.
• When GitHub still holds a runner on a job that died, cleanup is retried automatically for up to 30 minutes instead of waiting for a manual reconcile.
• A request that lost its cloud lease can now be reconciled after its VM is confirmed stopped.
• A job the access policy refused ends as runner_assignment_rejected, not as a plain cancellation.

See what is happening

• Jobs show the runner's stage next to their GitHub status: preparing, registering, waiting for a job, cleaning up, released.
• The desktop sends a macOS notification when Vectis needs you or work fails, even while its window is hidden. Clicking it opens the activity. Turn it off in Settings.
• A failed GitHub job now shows an error toast, even when its runner finished cleanly.

Workflow migration

Migration rewrites only the runs-on values it moves, byte for byte, and keeps comments and formatting. The desktop shows which jobs move to Vectis, which stay, and why, instead of two plain file previews.

Security

• Account linking and host isolation were hardened: each Linux instance has its own SSH host key, private fork policies are checked before a runner is registered, and Windows guests run with network isolation.
• Credentials are redacted from logs, operation details and stored diagnostics, including Windows bootstrap diagnostics.
• @modelcontextprotocol/sdk and sharp were updated.

Fixes

• Exit evidence is kept when VM file cleanup fails, so an instance can still be reconciled.
• Windows bootstrap failures keep their diagnostics.
• Jobs that GitHub reports with runner 0 are recognized as unassigned again.
• Jobs inherit the guest's normal umask, so files they create are no longer private to the runner user.
• A removed environment's ID can be prepared again.
• Requesting a runner for a job GitHub does not know reports job_not_found.

Documentation

New guides cover limits and boundaries, readiness, access policies, job logs, run control, Rosetta, egress, idle drain and request expiry, and the agent skill describes all of them.

Compatibility

The cloud backend is deployed and stays compatible with 0.1.x apps. Run control, job logs and readiness need 0.2.0 on the Mac. The app, CLI and service ship together.

Platform requirements and limitations

Apple Silicon Mac with macOS 15 or later. Ubuntu 24.04 ARM64 and macOS 26 ARM64 guests are supported; Windows 11 ARM64 is experimental. Guests are ARM64; Linux guests can run x86_64 tools through Rosetta when you opt in. Network egress is enforced only for Windows guests.