Brig's Launch List Has a Missing Cursor Image • The Weighted Average

NOFire’s September 15 Brig launch names six coding-agent profiles, but its current security documentation says Cursor has no published image. That leaves 1 of 6 named launch profiles with a documented readiness gap—a reason to evaluate the exact runtime and release, not adopt a sandbox from its integration list.

The integration list is not a deployment receipt

The announcement presents Brig as an Apache 2.0 microVM sandbox for coding agents on Apple Silicon Macs and Linux machines using x86_64 or ARM. It names Claude Code, Codex, Cursor, Gemini, Grok, and opencode, alongside support for custom OCI images. The useful proposition is containment around an agent that can operate autonomously, rather than relying only on conversational instructions to keep its work bounded.

The repository describes a prerelease in the 0.1.0-rc series. Its support matrix is more specific than the launch’s platform shorthand: Apple Silicon is required on macOS, and the normal macOS floor is 15, with a different backend for macOS 14. Intel Macs are unsupported. Linux brings its own runtime dependencies. For a fleet owner, these are rollout constraints, not installation trivia to discover after standardizing a developer image.

The arithmetic is deliberately modest. Count the six coding-agent names in the launch, then compare them with the security document’s statement that Cursor has no published image. One divided by six is 16.7%; more usefully, 1 of 6 named launch profiles cannot be treated as ready through a published image according to the current documentation. This is a documentation/readiness comparison, not a measured failure rate. It does not establish that the other five were tested independently or that a missing image will remain missing.

The distinction also avoids a misleading denominator. The repository describes eight built-in profiles, but those are not identical to the six coding-agent names in the announcement. Counting a general-purpose image or another application as a successful coding integration would make the launch list look more complete without answering whether a Cursor user can run the advertised path. The correct procurement unit is the workflow somebody intends to use.

Mutable documentation can lag a release. That is the strongest immediate counterpoint, and it should change the next step rather than disappear from the article. Ask for the exact version and published artifact that closes the discrepancy. If a current signed image and matching release documentation establish support, the Cursor objection is resolved. Until then, do not turn a present-tense integration claim into a promise to a development team.

There is a similar licensing qualification in the runtime documentation. The release says all components are Apache 2.0, while the runtime license table records the boot bundle’s license as unconfirmed and says its review dates to August 26. That older table may be stale; it is not proof of a licensing violation. It is evidence that a redistribution or enterprise-adoption review needs an explicit component inventory rather than relying on the umbrella license statement.

Isolation does not own the whole risk budget

Brig’s own security documentation draws the important boundary: the mounted project is writable, and those are the user’s real files. Hardware isolation can narrow access to the rest of the host without protecting the project from unwanted edits. A pilot should therefore use a recoverable working copy, preserve an independent checkpoint, and verify the resulting changes before merging. None of those duties vanishes because the process runs inside a microVM.

Network access is another separate decision. The default shared network allows internet access, while outbound-policy enforcement depends on the backend. Credential delivery and project mounts determine what the agent can read and use. Review those choices before unattended work. The recommendation is governance, not a claim that Brig is uniquely unsafe: a sandbox is useful precisely when its actual boundary is understood instead of being expanded in the buyer’s imagination.

Image verification also has a policy choice. The security guide documents a default warning mode and a stricter requirement mode. Teams should decide which trust rule they require and confirm it is effective on their selected platform. A successful boot proves that a process started; it does not prove that the organization chose the verification policy, artifact origin, or network boundary it intended.

The direct license price is not the total operating cost. The launch offers open-source software, but local compute, model access, setup, support, and review remain the operator’s responsibility. No retrieved evidence establishes an independent latency benchmark or a total-cost advantage against a managed sandbox. Brig’s own documentation explicitly says it does not stop an agent spending money. Keep account budgets and task-completion checks outside the isolation claim.

This complements the archive’s distinction between write access and approved work. The valuable control is not merely permitting an agent to act, but making its scope, credentials, and review path explicit. Today’s Cornelis qualification argument applies here too: a promising architecture does not remove the need to validate the configuration that actually ships.

Individual engineers with supported hardware and noncritical, recoverable projects can reasonably pilot Brig now. Teams requiring a stable support matrix, complete dependency licensing, and independently assessed isolation should not make it a mandatory baseline yet. Expand after the named profile works on the intended host, the documented controls match observed behavior, and recovery remains straightforward. Stop or narrow the rollout if those checks fail. The missing Cursor image is the first question, not the only one; the real purchase is a defensible boundary around useful work.