NVIDIA has released a new OpenShell version, changing security log formats and runtime account behavior for virtual machine sandboxes. Developers handling log collection and analysis or building sandbox images should review integrations and permissions against the new log specification and the account specified in the image.

1. Security log consumers move to a single format

Released on November 3, 2026, v0.1.7 emits security events only in OCSF 1.8.0 format. OCSF is an event classification standard whose schema defines event fields and structure. After updating, environments that selected older specifications also receive records in the new format: event data organized by field.

Deployments receiving 1.1 or 1.3 records must migrate. The release notes classify this as a breaking change. First check whether log parsers, programs that interpret logs, and detection rules, conditions that identify threats, support the new records if they assume the old fields and structure.

Settings for selecting older specifications are deprecated; supplied values are ignored and trigger a warning. This applies to gateway settings, which configure a component that relays communication between systems. It also covers version selection through deployment charts, bundles of installation settings, and environment variables.

Validation also follows the new format. According to the release notes, events from the supervisor, which manages sandboxes and virtual machine execution, and the gateway pass official OCSF 1.8.0 schema validation. The notes also say tests check event structure against JSON Schema, rules for validating JSON structure, exported by the OCSF schema server.

2. The account specified in the image is used at runtime

With the MicroVM driver, which uses lightweight virtual machines to reduce resource use, sandboxes built from registry images or root filesystem tar files run as the image's sandbox account. Previously, user and group IDs were fixed at 1000:1000.

This change fixes behavior to follow the runtime account documented in the image. If the image's sandbox account does not use user ID (UID) 1000, new sandboxes created from that image run under that account's UID.

Requesting the image's own UID through run_as_user is also supported. For image builders, this aligns account selection with actual execution. Environments with file ownership or access permissions tied to fixed IDs can review them against the image's runtime account.

3. Virtual machines start even with restrictive permissions

A virtual machine sandbox startup issue was also fixed. Virtual machine sandboxes can now start even when the gateway uses a strict umask, which restricts default permissions for new files. The release notes cite the packaged UMask=0077 as an example.

This fix concerns the gateway's file creation permissions. The image account change corrects who runs inside a sandbox. This fix instead focuses on allowing sandboxes to start in restrictive gateway runtime environments.

4. Check log integration and image permissions alongside installation

The release notes provide the following installation command. This is the original one-line example specifying the target version for the installation script.

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | OPENSHELL_VERSION=v0.1.7 sh

Unifying log formats allows collection and validation to follow one specification. Honoring image accounts aligns build-time user settings with runtime behavior. In return, log integrations relying on older specifications and permission configurations assuming fixed account IDs require migration work.

Successful installation alone is not enough to judge this update: the key is whether new logs can be read correctly and sandboxes can run under the account specified in the image.