apple/container

This system is a containerization platform for macOS that manages Linux containers, persistent virtual machines, and local Kubernetes clusters through a unified CLI and XPC-based API server. It provides comprehensive lifecycle management for containers, images, volumes, and networks, while handling low-level infrastructure tasks like kernel installation, DNS resolution, and socket forwarding. The architecture relies on a modular plugin system for runtime and network services, supporting both programmatic interaction via Swift clients and direct command-line usage.

51 changes.

The project underwent a major architectural shift by removing legacy container, network, and sandbox service implementations in favor of a new TOML-based configuration system and robust XPC communication layer. This period saw the introduction of comprehensive CLI commands for managing containers, images, networks, volumes, and system resources, alongside significant improvements to build processes, DNS resolution, and logging infrastructure.

41 changes.

The project restructured its core infrastructure by migrating from direct execution to a modular, XPC-based service architecture, introducing dedicated server and client libraries for containers, networks, volumes, and machines. This period focused on defining robust, typed resource models for all managed entities and implementing comprehensive integration tests to validate the new service-oriented design and CLI interactions.

A new 'list' (aliased as 'ls') command has been added to the System subcommand, allowing users to view the current system properties. The command supports output in either TOML (default) or JSON format, providing a structured way to inspect configuration details directly from the CLI.

Sources/ContainerCommands/System/Property · high confidence

The container CLI now includes a new 'registry list' (or 'ls') command that displays stored image registry logins, showing the hostname, username, and modification/creation dates in table format, or just the hostname in quiet mode. This new capability is part of a broader refactoring of the registry subcommands (login, logout, list) which have been moved from the CLI folder to the ContainerCommands module, renamed with a 'Registry' prefix, and updated to use the new AsyncLoggableCommand protocol and centralized logging infrastructure.

Sources/ContainerCommands/Registry · high confidence

The ContainerOS module now includes a DirectoryWatcher that exposes a readyEvents stream, allowing consumers to await the exact moment the watcher becomes active rather than guessing a startup delay. Additionally, on macOS, the new LocalNetworkPrivacy utility proactively triggers the system's local network privacy alert by connecting to link-local IPv6 addresses, ensuring users authorize the app before port publishing attempts occur.

Sources/ContainerOS · high confidence

The CVersion module now exposes the container builder shim version alongside the existing release and Swift containerization versions. This change adds a new \get\_container\_builder\_shim\_version()\ function and the corresponding \BUILDER\_SHIM\_VERSION\ macro, allowing users to query the version of the builder shim component. Additionally, license headers have been updated to remove "all rights reserved" and reflect the current year range.

Sources/CVersion · high confidence

The repository is initialized with essential project infrastructure, including a Swift Package Index configuration (.spi.yml) targeting Swift 6.2, a .swift-format-nolint file defining code style rules, and comprehensive documentation (BUILDING.md, CONTRIBUTING.md, README.md). The build system (Makefile) is established with targets for building, testing, and installing the container CLI, while also introducing code coverage instrumentation and warnings-as-errors enforcement. Additionally, a NOTICE.md file is added to track dependencies such as grpc-swift-2, swift-protobuf, and swift-nio, and legacy files like CODE-OF-CONDUCT.md and SECURITY.md are removed in favor of inherited guidelines.

(repo-wide) · high confidence

The CoreImages plugin is now available as a standalone component, providing an XPC interface for managing OCI images. This includes a new \ImagesHelper\ entry point that bootstraps the XPC server to handle image operations (pull, push, list, delete, etc.) and content store interactions. The plugin's behavior is controlled by a new \config.toml\ file, which defines service metadata and specifies that the core service should load at boot.

Sources/Plugins/CoreImages · high confidence

The Linux container runtime plugin now includes a dedicated helper executable (\container-runtime-linux\) that manages Linux sandboxes via an XPC service. This helper exposes a comprehensive set of runtime operations including process lifecycle management (start, stop, kill, resize, wait), container networking, file transfer (copy in/out), disk snapshots, and cleanup. Configuration is now handled through a \config.toml\ file, allowing control over service loading behavior. The implementation sets specific system limits (file descriptors) and configures network interface strategies for isolated and non-isolated modes.

Sources/Plugins/RuntimeLinux · high confidence

Added a new \RegistryResource\ struct that models a configured container registry endpoint, including its hostname, authentication username, timestamps, and metadata labels. This resource provides built-in validation for registry hostnames (supporting DNS names, IPv6 addresses, and ports) conforming to OCI distribution specifications and includes an initializer to convert from existing \RegistryInfo\ data, enabling the system to manage registry credentials and configuration as first-class managed resources.

Sources/ContainerResource/Registry · high confidence

This change introduces the \container k8s\ plugin, providing a new set of commands to manage local Kubernetes clusters running inside containers. Users can now create clusters with \container k8s create\ (including support for custom CNI manifests and node images), list them with \container k8s list\, delete them with \container k8s delete\, and load container images into the cluster's containerd runtime using \container k8s load-image\. The plugin also handles kubeconfig management via \container k8s write-config\, automatically merging the cluster context into the user's local kubeconfig file. The implementation uses a \NodeProvisioner\ protocol to manage Linux node containers, supporting both control-plane and worker roles.

Sources/ContainerK8s · high confidence

This change adds the client and server components for managing persistent Linux container machines. The client-side \MachineClient\ exposes operations to create, delete, list, boot, stop, and inspect machines, as well as set a default machine, communicating with the service via XPC. The server-side \MachinesService\ and \MachinesHarness\ handle these requests, managing machine state persistence, boot configuration, and integration with the underlying container runtime. Supporting types like \MachineConfiguration\, \MachineSnapshot\, and \MachineBundle\ define the data structures for machine identity, platform selection, and bundle synchronization.

Sources/Services/MachineAPIService · high confidence

Adds a new \machine-apiserver\ plugin that provides an XPC-based interface for managing persistent Linux VMs. The server exposes operations to list, create, delete, boot, stop, inspect, and configure machines, along with retrieving logs. It includes a startup command that initializes the XPC server with routes for these machine lifecycle actions, and ships with shell scripts to handle first-time user setup (creating users and granting sudo access) and system initialization (booting the VM and setting the hostname).

Sources/Plugins/MachineAPIServer · high confidence

The CLI now includes a new \network\ command group with subcommands for creating, listing, inspecting, deleting, and pruning container networks. Users can create networks with specific IPv4/IPv6 subnets, host-only modes, and plugin selections; list and inspect networks in table or JSON formats; delete networks (with protection against removing builtin networks); and prune unused networks. This replaces the previous health-check-based infrastructure with a dedicated network resource model.

Sources/ContainerCommands/Network · high confidence

The \container\ CLI now includes a new \k8s\ plugin that allows users to manage local Kubernetes development clusters. This feature introduces commands to create, list, switch between, and delete clusters, as well as load local images into the cluster and write kubeconfig files. The plugin is marked as experimental and relies on the \kind\ tool for cluster provisioning, bundling the necessary \kindnet\ CNI manifest for networking. This functionality is implemented in the \Sources/Plugins/K8s\ directory, replacing the previous health-check harness with a dedicated plugin entry point.

Sources/Plugins/K8s · high confidence

This change introduces the core server-side implementation for managing container volumes, including the VolumesService actor and the VolumesHarness XPC handler. Users can now create, list, inspect, delete, and check disk usage of volumes through the container API. The service persists volume configurations using a FilesystemEntityStore and includes a migration to update legacy volume metadata from 'createdAt' to 'creationDate. The implementation supports volume drivers (defaulting to 'local'), driver options, and labels, while ensuring thread-safe operations via async locks.

Sources/Services/ContainerAPIService/Server/Volumes · high confidence

This change adds a new \container machine\ command group (aliased as \m\) to manage persistent Linux VMs, replacing the previous image-focused commands \prune\ and \save\ which have been removed. The new subcommands include \create\ (with options for CPUs, memory, home directory mounts, and nested virtualization), \run\ (to execute commands or shells), \stop\, \delete\, \list\, \inspect\, \logs\, \set\ (to update configuration like cpus or memory), and \set-default\. The implementation includes pre-flight checks for nested virtualization support on Apple Silicon M3+ with macOS 15+.

Sources/ContainerCommands/Machine · high confidence

The ContainerResource module now includes a foundational error-handling framework via the \AppError\ protocol and \AppErrorCode\ enum, enabling clients to present structured error messages with stable codes and metadata. Additionally, a new \ResourceLabels\ type has been added to manage key-value metadata for managed resources, enforcing validation rules for label keys and values (including Docker and OCI naming patterns) and providing system-defined keys for roles such as 'builtin' and 'plugin'. These changes also introduce a \ManagedResource\ protocol that standardizes resource identification and labeling, and a \FileManager\ extension for calculating allocated disk space, supporting more robust resource management and storage accounting.

Sources/ContainerResource/Common · high confidence

The CLI now includes a dedicated 'volume' command group (aliased as 'v') with subcommands for creating, listing, inspecting, deleting, and pruning container volumes. Users can create volumes with labels, driver options, and size constraints; list volumes in table or quiet formats; inspect specific volumes; delete individual or all volumes; and prune unused volumes to reclaim disk space.

Sources/ContainerCommands/Volume · high confidence

A new \ContainerTestSupport\ library has been introduced to provide structured and unstructured helpers for CLI integration tests. It includes a \ContainerFixture\ class that manages test-scoped resources (containers, images, volumes, networks, machines) with automatic cleanup, along with dedicated helper extensions for build contexts, container lifecycle, image management, machine operations, network connectivity, SSH agent mocking, system configuration, and volume handling. The package also provides utilities for caching and restoring warmup images from local tar archives, a loopback HTTP file server for offline testing, and kernel fixture helpers to capture and repackage installed kernels for integration tests.

Sources/ContainerTestSupport · high confidence

A new ImageResource struct has been introduced to represent OCI images, conforming to the ManagedResource protocol. This model structures image data into a configuration (containing the reference, creation date, and descriptor) and a list of platform-specific variants (including platform, digest, size, and config). The resource exposes a simplified ID (stripping the hash scheme from the digest), a user-facing name, creation date, and labels derived from annotations. It also includes a display reference for cleaner listings and supports JSON encoding/decoding for serialization.

Sources/ContainerResource/Image · high confidence

The SocketForwarder module now provides TCP and UDP port forwarding, allowing users to forward network traffic from a local proxy address to a backend server. This includes a TCP forwarder that establishes a connection to the backend before relaying data, and a UDP forwarder that manages per-client backend channels with an LRU cache to handle multiple concurrent clients. The implementation introduces new components such as ConnectHandler for managing backend connections, GlueHandler for channel pairing, and LRUCache for managing UDP proxy state, along with a unified SocketForwarder protocol and SocketForwarderResult for managing the lifecycle of the forwarded connections.

Sources/SocketForwarder · high confidence

This release introduces a new set of Swift client libraries in the \Sources/Services/ContainerAPIService/Client\ directory, enabling programmatic interaction with the container API server over XPC. The library provides dedicated clients for managing container lifecycles (\ContainerClient\), virtual networks (\NetworkClient\), and volumes (\ClientVolume\), as well as utilities for system health checks (\ClientHealthCheck\), disk usage statistics (\ClientDiskUsage\), and platform resolution (\DefaultPlatform\). It also includes a \PacketFilter\ client for managing macOS firewall rules and a \Parser\ module for handling CLI argument parsing and configuration. This new architecture replaces previous direct execution models with a structured, asynchronous XPC communication layer.

Sources/Services/ContainerAPIService/Client · high confidence

The CLI now includes several new container management capabilities. Users can clean specific containers with the new \container clean\ command, copy files between the host and containers using \container copy\ (aliased as \cp\), and export a container's filesystem to a tar archive via \container export\. The \container list\ command now explicitly lists running containers by default (with an \--all\ flag to include stopped ones), and \container prune\ allows users to remove all stopped containers to reclaim disk space. Additionally, \container stats\ provides real-time resource usage monitoring for containers, supporting both streaming terminal output and static JSON/table formats.

Sources/ContainerCommands/Container · high confidence

A new \HealthCheckHarness\ component has been added to the Container API Service server, providing a structured health check endpoint. When queried, it returns comprehensive status information including application and installation roots, log directory paths, the API server version, git commit hash, build type, and application name. This enhancement allows clients to gain richer visibility into the server's operational state and configuration, supporting better diagnostics and monitoring capabilities.

Sources/Services/ContainerAPIService/Server/HealthCheck · high confidence

The \container system\ command group now includes new subcommands: \df\ to report disk usage for images, containers, and volumes; \status\ to display detailed service, client, and host information; and \version\ to show CLI and API server version details. The \system start\ command has been updated to explicitly manage the \container-apiserver\ launchd service and verify its health before proceeding. Additionally, \system stop\ now checks if the APIServer is running before attempting to stop containers, skipping the container shutdown step if the service is already down, and the \system logs\ command now validates the \--last\ argument format.

Sources/ContainerCommands/System · high confidence

The \NetworkService\ and \NetworkState\ source files in \Sources/Services/ContainerNetworkService\ have been deleted. This removes the local implementation responsible for managing container network states, allocating IP addresses via an \AttachmentAllocator\, and handling XPC messages for network operations such as allocation, deallocation, and lookup.

Sources/Services/ContainerNetworkService · high confidence

The \KernelService\ actor, which previously handled the installation of kernel binaries from local paths or tar archives and managed default kernel symlinks, has been removed from the APIServer Kernel module. This eliminates the local file-system-based kernel management logic (including download, extraction, and symlink creation) from this component.

Sources/APIServer/Kernel · high confidence

The \SandboxService.swift\ file, which contained the core actor logic for managing container lifecycle, networking, and process execution, has been deleted from the \Sources/Services/ContainerSandboxService\ directory.

Sources/Services/ContainerSandboxService · high confidence

The \builder start\ and \builder status\ CLI commands have been removed from the CLI. This eliminates the ability to manually start the BuildKit builder container with specific CPU and memory allocations, check its status, or manage its lifecycle via these specific subcommands.

Sources/CLI/Builder · high confidence

The \Flags.swift\, \Parser.swift\, \SandboxClient.swift\, and \Utility.swift\ files in \Sources/ContainerClient\ have been deleted. This removes the previous CLI flag definitions, argument parsing logic, sandbox communication client, and utility functions that were used to configure and run containers, indicating a structural shift in how the container client handles these responsibilities.

Sources/ContainerClient · high confidence

The \NetworksService\ actor, which previously managed network creation, listing, deletion, and DNS hostname lookups via a plugin-based architecture, has been removed from the codebase. This change eliminates the legacy network management logic that relied on \ContainerNetworkService\ and \ContainerPersistence\ for state storage and plugin loading, indicating a shift in how network resources are handled within the API server.

Sources/APIServer/Networks · high confidence

The \ClientContainer\, \ClientNetwork\, \ClientDefaults\, and \ContainerConfiguration\ files in \Sources/ContainerClient/Core\ have been deleted. This removes the previous XPC-based client implementation that handled container lifecycle, network management, and configuration defaults via the \com.apple.container.apiserver\ service. Users relying on this specific client layer for container operations will need to use the new underlying service or API.

Sources/ContainerClient/Core · high confidence

The \ContainersHarness\ and \ContainersService\ files in the APIServer Containers module have been deleted. This removes the previous implementation of the container management service, including its XPC message handling, container lifecycle logic (list, create, delete, logs), and internal state management, indicating a structural shift in how the API server interacts with the container runtime.

Sources/APIServer/Containers · high confidence

The \RegistryDefault\ command group, which previously allowed users to set, unset, and inspect the default image registry via \default set\, \default unset\, and \default inspect\ subcommands, has been removed from the CLI. This file deletion eliminates the ability to configure the default registry domain through this specific interface.

Sources/CLI/Registry · high confidence

The \RuntimeLinuxHelper\ executable, which previously served as the XPC service for managing Linux sandboxes, has been removed from the codebase. This eliminates the local XPC server that handled sandbox lifecycle operations such as bootstrap, process creation, state management, and resource resizing, indicating a shift away from this specific helper architecture.

Sources/Helpers/RuntimeLinux · high confidence

The \container system start\ command has been removed from the CLI. This command previously handled starting the container API server, verifying its health, and prompting users to install missing runtime dependencies such as the kernel and initial filesystem. Users will no longer be able to use this specific command to bootstrap or start the container system services.

Sources/CLI/System · high confidence

The \Sources/CLI/Image/ImageList.swift\ file has been deleted, removing the \image list\ (and \image ls\) command from the CLI. Users will no longer be able to list local images via this command; this functionality has been removed from the product.

Sources/CLI/Image · high confidence

The \Sources/CLI/System/DNS/DNSDefault.swift\ file, which implemented the \system dns default\ command group (including \set\, \unset\, and \inspect\ subcommands for managing the default local DNS domain), has been removed. This change eliminates the ability to configure the default DNS domain via this specific CLI interface.

Sources/CLI/System/DNS · high confidence

The \Sources/Helpers/Images/ImagesHelper.swift\ file, which previously provided a standalone command-line tool (\container-core-images\) for managing OCI images via an XPC service, has been removed. This eliminates the separate process that handled image operations such as pull, list, delete, tag, push, save, load, unpack, and prune, along with content store management and snapshot handling.

Sources/Helpers/Images · high confidence

The main entry point for the CLI has been moved from the \Application\ struct in \Sources/CLI/Application.swift\ to a new \ContainerCLI\ enum in \Sources/CLI/ContainerCLI.swift\. This change reorganizes the client libraries by renaming the previous network configuration file to \ContainerCLI.swift\ and updating it to call \Application.main()\, effectively decoupling the entry point logic from the application definition while maintaining the same runtime behavior.

Sources/CLI · high confidence

The container CLI now uses a unified output rendering infrastructure that supports JSON, YAML, TOML, and table formats, with JSON output specifically configured to avoid escaping slashes. Error reporting has been improved with a new AggregateError type that displays multiple underlying errors on separate lines, and the help system has been reorganized to resolve subcommand paths correctly. Additionally, progress output now intelligently falls back to plain text when stdout is not a TTY, and a new Color Progress Output Mode is available for enhanced visual feedback.

Sources/ContainerCommands · high confidence

The version output logic has been refactored to ensure the \--version\ flag and programmatic version queries behave consistently. A key improvement is that the application bundle is now correctly located by resolving symlinks in the executable path before walking up to the \.app\ directory, fixing issues where symlinked containers failed to report their version. The version string now includes the build type (debug/release) and the short git commit hash alongside the bundle version.

Sources/ContainerVersion · high confidence

The container management logic has been restructured into a dedicated service layer under \Sources/Services/ContainerAPIService/Server\. This introduces \ContainersService\ and \ContainersHarness\ to handle core container lifecycle operations (list, bootstrap, stop, dial, wait, resize, kill, create) via XPC, replacing the previous monolithic API server implementation. A new \DiskUsageService\ and \DiskUsageHarness\ have been added to calculate and report disk usage statistics for images, containers, and volumes. Additionally, the \PluginsService\ and \PluginsHarness\ have been moved to this new location and updated to support a \debug\ flag for plugin registration, while the old CLI \SystemRestart\ command has been removed in favor of the new service-oriented architecture.

Sources/Services/ContainerAPIService/Server/Containers · high confidence

The container build system now automatically falls back to using a Containerfile if a Dockerfile is not found in the build context. It also supports building directly to the local filesystem via the new 'local' export type. Users will see a progress bar with download speed and size indicators during image pulls, and the build process now correctly resolves symlinks within the build context to ensure accurate file inclusion.

Sources/ContainerBuild · high confidence

The container resource layer has been reorganized into the ContainerResource/Container module, introducing a comprehensive ContainerConfiguration that supports new container options including Linux capabilities (capAdd/capDrop), /dev/shm size limits, masked and read-only paths, and a custom stop signal. The container lifecycle now tracks a startedDate, and the runtime status model includes a new 'stopping' state. Filesystem handling has been updated to support named volumes and defaults to a cached mode to fix virtualization filesystem issues, while port and socket publishing now use FilePath types for better path validation and backward compatibility with legacy URL formats.

Sources/ContainerResource/Container · high confidence

The DNS subcommands (list, create, delete) have been refactored to use a unified logging and output infrastructure. The \create\ command now accepts a \--localhost\ option to configure a packet filter redirect rule for the specified domain, ensuring traffic is correctly routed. The \list\ command introduces \--format\ (supporting table, yaml, toml) and \--quiet\ options for flexible output control. Additionally, the \delete\ command now properly cleans up associated packet filter rules when a localhost redirect was previously configured, and all commands provide more accurate error messages.

Sources/ContainerCommands/System/DNS · high confidence

The DNS server in Sources/DNSServer now returns a NODATA response (noError with empty answers) for AAAA queries when an A record exists, instead of returning NXDOMAIN. This prevents musl libc-based clients from incorrectly treating the missing IPv6 address as a non-existent domain. The change also introduces a new DNS record binding layer (DNSBindError, DNSName, Message, etc.) with Sendable types, adds packet size validation, and improves error handling for malformed DNS messages.

Sources/DNSServer · high confidence

The \kernel set\ command now supports verifying the integrity of kernel archives via a required \--digest\ flag when installing from remote URLs, and introduces a \--force\ flag to overwrite existing kernels. Additionally, the command now reads kernel installation details (URL, binary path, and digest) from the system configuration when using the \--recommended\ flag, replacing the previous hardcoded client defaults.

Sources/ContainerCommands/System/Kernel · high confidence

The ImagesService has been refactored to support multiple image saves to a tarfile, parallel layer downloads via a new maxConcurrentDownloads parameter, and a force-load option for image loading. The service now exposes disk usage reporting through a new imageDiskUsage route, allowing users to see total, active, and reclaimable sizes. Additionally, the image prune operation has been renamed to imageCleanupOrphanedBlobs, and the XPC interface has been updated to use imageSize instead of size for byte counts.

Sources/Services/ContainerImagesService · high confidence

The volume subsystem now uses dedicated \VolumeConfiguration\ and \VolumeResource\ types to represent volume data. \VolumeConfiguration\ holds the persistent properties (name, driver, format, source, labels, options, size) and handles JSON decoding with backward compatibility for the deprecated \createdAt\ field. \VolumeResource\ wraps this configuration and conforms to \ManagedResource\, exposing a unified interface for ID, name, creation date, and validated labels. This change standardizes how volume data is structured and serialized, replacing previous ad-hoc representations with a consistent, typed model.

Sources/ContainerResource/Volume · high confidence

The ContainerLog module now includes new FileLogHandler and StderrLogHandler implementations, allowing users to direct logs to specific files or standard error streams in addition to the existing OS log facility. The ServiceLogger bootstrap method has been updated to support these new handlers, enabling file-based logging via a configurable log path. Additionally, the OSLogHandler's mapping of warning-level logs has been changed to output at the default OS log level instead of error, aligning warning messages with standard system logging behavior.

Sources/ContainerLog · high confidence

The kernel service now allows users to force the replacement of an existing kernel binary during installation via a new \force\ flag, and requires (or accepts) a SHA-256 digest when installing kernels from remote archives to verify integrity before unpacking. These capabilities are exposed through the \KernelHarness\ XPC interface, which now parses \kernelForce\ and \kernelDigest\ parameters from incoming messages and passes them to the underlying \KernelService\ methods.

Sources/Services/ContainerAPIService/Server/Kernel · high confidence

The Linux container runtime service has been reorganized into a new directory structure, introducing a dedicated RuntimeService actor to manage VM-backed container lifecycles via XPC. Network interface strategies have been updated to explicitly handle IPv4 addresses, gateways, MAC addresses, and MTU settings (defaulting to 1280), replacing the previous generic attachment model. Additionally, a new LinuxRuntimeData structure replaces the previous command-line executable helper, standardizing how runtime configuration data is passed between the CLI and the Linux runtime.

Sources/Services/RuntimeLinux · high confidence

The network management API has been updated to return \NetworkResource\ objects rather than \NetworkState\ objects in its responses. This change affects the \list\, \create\, and \delete\ operations exposed via the XPC interface, where the response keys have shifted from \.networkStates\/\.networkState\ to \.networkResources\/\.networkResource\. For users, this means the structure of the data returned by network queries and creation requests has changed to align with the new resource model, potentially requiring updates to any clients that parse the previous \NetworkState\ format.

Sources/Services/ContainerAPIService/Server/Networks · high confidence

The network service has been restructured to replace the previous per-call client pattern with persistent XPC sessions, requiring callers to use a new \connect()\ method to obtain a session for \allocate()\ calls. The API has been simplified by removing the \deallocate\ and \disableAllocator\ routes, as the network helper now automatically releases allocations when the session closes. Additionally, the service now supports optional MAC address specification during allocation, allows hostname reuse (returning the existing IP if a hostname is already registered), and has renamed the network state query from \state\ to \status\ while removing the \allocatorDisabled\ route.

Sources/Services/Network · high confidence

The NetworkVmnet plugin now uses a dedicated config.toml file for service configuration, replacing previous inline or external setup methods. The helper executable has been restructured: the main entry point (NetworkVmnetHelper.swift) now solely defines the CLI command structure, while the actual startup logic has moved to NetworkVmnetHelper+Start.swift. This change introduces support for distinct network variants (allocationOnly and reserved) and allows explicit configuration of IPv4 and IPv6 subnets via new command-line options, replacing the previous single subnet argument. The network configuration model now uses 'name' instead of 'id' for identification, and the XPC service routes have been simplified to expose status, allocate, and lookup operations via a new harness pattern.

Sources/Plugins/NetworkVmnet · high confidence

The container persistence layer now uses TOML files (config.toml) for configuration, replacing the previous format. Configuration is loaded from layered files with user settings taking precedence over system defaults, and the system now supports scoped plugin configurations. The new \ConfigSnapshotDecoder\ provides custom decoding for types like URLs and memory sizes, while \ConfigurationLoader\ handles the file resolution and decoding process. The system also includes path utilities for resolving configuration directories and a \FilePath\ extension for symlink resolution.

Sources/ContainerPersistence · high confidence

Users can now update the container tool to a specific or latest release version using the new \scripts/update-container.sh\ script, which handles package downloads and installations. A new \scripts/pre-commit.fmt\ script has been added to automate formatting and license checks via \make check\. The \scripts/ensure-container-stopped.sh\ script now supports stopping container services across all launchd domains (system, user, and GUI) with the \-a\ flag, rather than just the current domain. Additionally, \scripts/ensure-hawkeye-exists.sh\ now supports auto-installation via the \--auto-install\ flag or \HAWKEYE\_AUTO\_INSTALL=1\ environment variable, and \scripts/install-hawkeye.sh\ has been updated to install hawkeye v6.5.1 with SHA-256 checksum validation on Apple Silicon. The \scripts/install-init.sh\ script now accepts \--app-root\ and \--log-root\ arguments, and \scripts/uninstall-container.sh\ now removes user defaults when the \-d\ flag is used.

scripts · high confidence

The plugin system now prefers TOML-based configuration files (config.toml) over the legacy JSON format, with a warning logged when falling back to JSON. Plugin discovery and loading have been refactored to use explicit ApplicationRoot, InstallRoot, and LogRoot structures, allowing these paths to be overridden via environment variables (CONTAINER\_APP\_ROOT, CONTAINER\_INSTALL\_ROOT, CONTAINER\_LOG\_ROOT). The default plugin directory has moved to {install-root}/libexec/container-plugins, and plugin factories now support a new create(parentURL, name) method for targeted lookups. Additionally, the ServiceManager now throws errors instead of silently returning empty results on launchctl failures, and plugin loading validates plugin names to prevent directory traversal.

Sources/ContainerPlugin · high confidence

The TerminalProgress library introduces an \OutputMode\ configuration option allowing users to choose between \.ansi\ (default), \.plain\, and \.color\ rendering. The \.plain\ mode outputs newline-separated text without ANSI escape codes, making it suitable for non-terminal environments or log files, while \.color\ mode adds ANSI color codes to the progress bar. Internally, the progress bar's state is now protected by a \Mutex\ (replacing the previous \SendableProperty\ dependency) to ensure thread-safe access, and the \finish()\ method now respects the \clearOnFinish\ setting specifically for plain mode output behavior.

Sources/TerminalProgress · high confidence

The network management API has been restructured to separate persistent configuration from runtime status, aligning with Kubernetes and Docker patterns. Network resources now expose a \configuration\ block (containing name, mode, subnets, labels, and plugin details) and a \status\ block (containing assigned IPv4/IPv6 subnets and gateways). The \NetworkConfiguration\ type now uses \name\ as the primary identifier (with \id\ retained for backward compatibility) and supports multiple network plugins via a \plugin\ string and \options\ dictionary, replacing the legacy \pluginInfo\ structure. The \Attachment\ model has been renamed to \AttachmentConfiguration\ and simplified to hold attachment options (hostname, MAC, MTU) rather than resolved addresses, which are now part of the network status. Additionally, a \hostOnly\ network mode has been added to allow containers to communicate within the same subnet without external routing.

Sources/ContainerResource/Network · high confidence

The API server's entry point has been restructured to use a dedicated 'start' subcommand, centralizing the initialization of XPC routes, services, and background tasks. This change also introduces a new LocalhostDNSHandler that monitors configuration files to resolve container hostnames, complementing the existing resolver. Additionally, the DNS handling logic has been refined to correctly return NODATA responses for IPv6 queries when a hostname exists but lacks an AAAA record, preventing resolution failures on clients using musl libc.

Sources/APIServer · high confidence

The builder management commands (start, stop, delete, status) have been moved from the CLI folder to the ContainerCommands/Builder directory and refactored to use the new ContainerAPIClient instead of the legacy ContainerClient. This change standardizes the command structure by adopting AsyncLoggableCommand and adding logging options, while also updating the delete command to support an 'rm' alias and improving error handling for the status command.

Sources/ContainerCommands/Builder · high confidence

The CAuditToken module has been refactored to provide low-level C utilities for handling XPC audit tokens, replacing previous Swift-based service interfaces. The implementation now includes a C header defining the \xpc\_dictionary\_get\_audit\_token\ function and a corresponding source file required to generate the \CAuditToken.o\ object, shifting the capability from high-level Swift protocol definitions to direct C-level access for XPC security contexts.

Sources/CAuditToken · high confidence

The image management commands have been restructured to improve usability and output consistency. The \image list\ command now supports a \--verbose\ flag to display detailed platform-specific information (OS, architecture, size) and a \--quiet\ flag for simplified reference output. The \image prune\ command now accepts an \-a\ (all) flag to remove all unused images, not just dangling ones. The \image delete\ command introduces a \--force\ flag to ignore errors for missing images. Additionally, \image save\ now routes the list of saved references to stderr when writing to stdout to prevent stream corruption, and \image push\ prints the image reference to stdout on success.

Sources/ContainerCommands/Image · high confidence

The container runtime client has been reorganized to support a more scalable plugin architecture. This change introduces a new \InterfaceStrategy\ protocol and \NetworkBootstrapInfo\ struct to handle network attachment mapping and plugin identification, replacing previous XPC compatibility code. The \RuntimeClient\ now communicates with the runtime service via a refined XPC interface, exposing routes for sandbox lifecycle, process management, and file operations. Additionally, the \ExitMonitor\ has been updated to track work completion using \ExitStatus\ instead of raw exit codes, and configuration handling is centralized in \RuntimeConfiguration\ for better serialization and persistence.

Sources/Services/Runtime · high confidence

The XPC communication layer now supports persistent sessions on both client and server sides, allowing applications to register disconnect handlers that are invoked when the remote peer closes the connection. On the server side, every request is now validated to ensure the client's effective user ID matches the server's, rejecting unauthorized requests. Additionally, error messages sent over XPC now include the original error's cause string, and the server provides a helper to wrap legacy route handlers that do not accept the new session parameter.

Sources/ContainerXPC · high confidence

Added integration tests for CLI machine commands; Added integration tests for Kubernetes cluster lifecycle and networking; Added integration tests for container CLI commands; Added integration tests for container build CLI builder; Added integration tests for container image warmup; Added integration tests for container run capabilities, options, and security paths; Added integration tests for image and registry CLI commands; Added test coverage for ContainerAPIClient core components; Added test coverage for ContainerResource models and validation logic; Added test coverage for container disk usage validation, kernel archive integrity, and runtime configuration variants; Added test coverage for container persistence and versioning components; Added tests for AttachmentAllocator; Added tests for CLI help resolution, output formatting, and system status; Added tests for DirectoryWatcher readiness and directory recreation; Added tests for K8s plugin functionality; Added tests for SocketForwarder components; Added tests for container build context boundary enforcement and file resolution; Added unit tests for ContainerPlugin path resolution, configuration, and plugin lifecycle; Expanded test coverage for DNS server record handling and resolver behavior; Migrate ProgressBarTests to Swift Testing; New integration tests for system CLI commands; Removal of obsolete CLITest.swift utility file; Removed CLI run options integration tests; Removed legacy image CLI test suite; Removed obsolete CLI build and run test infrastructure.

The project has upgraded to Swift tools version 6.2 and performed a comprehensive dependency update. Key library upgrades include Containerization (0.1.34 to 0.45.0), swift-argument-parser (1.5.0 to 1.8.2), swift-crypto (3.12.3 to 3.15.1), and swift-certificates (1.10.0 to 1.19.3). The networking stack has been modernized by replacing the legacy grpc-swift (1.26.0) with grpc-swift-2 (2.4.2) and grpc-swift-nio-transport (2.9.0), and DNS resolution now uses grpc-swift-protobuf (2.4.1) instead of the separate DNS and DNSClient packages. New dependencies added include swift-configuration, swift-configuration-toml, and swift-distributed-tracing, while swift-collections was pinned to 1.5.1.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 68 → 62 (-5.7)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 96 → 88 (-8.2)
• Architecture 97 → 98 (+0.5)
• Maturity 58 → 59 (+0.3)
• Readiness 66 → 61 (-5.0)
• Security 72 → 57 (-15.4)

• Change coupling: ClientImage.swift ↔ ImagesServiceHarness.swift (Sources/Services/ContainerAPIService/Client/ClientImage.swift)
• Change coupling: ContainerClient.swift ↔ ContainersHarness.swift (Sources/Services/ContainerAPIService/Client/ContainerClient.swift)
• Change coupling: ContainerClient.swift ↔ ContainersService.swift (Sources/Services/ContainerAPIService/Client/ContainerClient.swift)
• Change coupling: ContainerCreate.swift ↔ ContainerRun.swift (Sources/ContainerCommands/Container/ContainerCreate.swift)
• Change coupling: SystemStart.swift ↔ KernelService.swift (Sources/ContainerCommands/System/SystemStart.swift)
• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• LLM evaluation failed
• No exposed public API
• Off-boarding risk: anonymized user #1
• Off-boarding risk: anonymized user #2
• Scanner failed to run — not a clean result
• Test reliability not included
• TooManyMethods: ContainerFixture (Sources/ContainerTestSupport/ContainerFixture.swift)
• complexity unreadable for .swift — churn × complexity hotspots could not be measured

• Archiver.compress (cognitive 21) (Sources/Services/ContainerAPIService/Client/Archiver.swift)
• BuildFSSync.walk (cognitive 16) (Sources/ContainerBuild/BuildFSSync.swift)
• Change coupling: ClientImage.swift ↔ ImagesService.swift (Sources/Services/ContainerAPIService/Client/ClientImage.swift)
• Change coupling: ContainerConfiguration.swift ↔ Flags.swift (Sources/ContainerResource/Container/ContainerConfiguration.swift)
• Change-coupling hub: ContainerClient.swift → ContainersHarness.swift, ContainersService.swift, RuntimeClient.swift (Sources/Services/ContainerAPIService/Client/ContainerClient.swift)
• ContainerizationProgressAdapter.handler (cognitive 19) (Sources/Services/ContainerAPIService/Client/ContainerizationProgressAdapter.swift)
• Coverage not measured — Swift suite
• DNSName.bindBuffer (cognitive 26) (Sources/DNSServer/Records/DNSName.swift)
• DNSServer.handle (cognitive 17) (Sources/DNSServer/DNSServer.swift)
• Dependency hygiene PARTLY measured — SwiftPM pinning read, dependency currency NOT established
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (10 lines × 2) (Sources/ContainerCommands/TableOutput.swift)
• Duplicated block (10 lines × 2) (Sources/Services/ContainerAPIService/Client/Utility.swift)
• Duplicated block (10 lines × 2) (Sources/Services/RuntimeLinux/Server/RuntimeService.swift)
• Duplicated block (10 lines × 3) (Sources/Services/ContainerAPIService/Server/Kernel/KernelService.swift)
• Duplicated block (10 lines × 5) (Sources/Services/ContainerAPIService/Server/Containers/ContainersService.swift)
• Duplicated block (10–13 lines × 2) (Sources/ContainerPlugin/PluginFactory.swift)
• Duplicated block (11 lines × 4) (Sources/Services/ContainerAPIService/Server/Containers/ContainersService.swift)
• Duplicated block (12 lines × 12) (Sources/Services/ContainerAPIService/Server/Containers/ContainersService.swift)
• …and 296 more

• 45 commits — 34 feature/other, 11 fixes

• (root) — 8 commits
• Sources/Services — 8 commits
• Sources/ContainerK8s — 5 commits
• Sources/Plugins — 4 commits
• Sources/ContainerCommands — 3 commits
• Tests/IntegrationTests — 3 commits
• Sources/ContainerBuild — 2 commits
• .github/workflows — 1 commit
• Sources/ContainerPersistence — 1 commit
• Sources/ContainerTestSupport — 1 commit
• Sources/SocketForwarder — 1 commit
• Tests/ContainerOSTests — 1 commit
• Tests/TerminalProgressTests — 1 commit
• docs/command-reference.md — 1 commit
• docs/how-to.md — 1 commit
• docs/kubernetes.md — 1 commit
• docs/technical-overview.md — 1 commit
• docs/tutorials — 1 commit
• skills/container — 1 commit

• fix: Fix Globber dropping directory contents under a symlinked ancestor (#2252)
• fix: Fix a compilation error (#2119)
• fix: Fix a compilation error (#2234)
• fix: Fix a compilation warning (#2251)
• fix: Fix compilation warnings (#2235)
• fix: Fix container egress loss after localhost DNS changes (#2256)
• fix: Fix tmpfs mount source field left empty for --mount type=tmpfs (#2138)
• fix: Integration test: fix k8s test with scoped domain. (#2104)
• fix: Integration test: fix username/uid flake. (#2086)
• fix: fix(k8s): correct k8s control plane components version using the user specified node image version (#2271)
• fix: fix: handle container clean failing on read-only named volume mounts (#2228)
• change: Add container skill (#2154)
• change: Add identifier validation tests for the disk-usage routes (#2136)
• change: Avoid escaping slashes in JSON output (#2205)
• change: Bump CZ to 0.45.0 (#2250)
• change: Do not set default maskedPaths and readonlyPaths for container machines (#2137)
• change: Enhance container system status command output (#1769)
• change: Extracts createPluginLoader() for use by container k8s. (#2115)
• change: Integration test: cache warmup image tarfiles. (#2074)
• change: K8s plugin (#2044)
• …and 25 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

apple/container was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.