Codex review flagged that a mistyped "@0" or "@-1" parsed to a non-nil
ppi that persisted and was fed straight into
VZMacGraphicsDisplayConfiguration, bypassing the 72 fallback and risking
a display that fails to build until the user manually resets it.
Guard both ends: the --display parser now keeps only a positive PPI
(zero/negative ignored just like non-numeric input), and
effectivePixelsPerInch treats a non-positive stored value (e.g. from a
hand-edited config) as unset, falling back to 72.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`tart set --display WIDTHxHEIGHTpx` always configured the guest's pixel
framebuffer at a hardcoded 72 PPI, so a macOS guest never exposed a HiDPI
(2x/Retina) mode when the host display was non-Retina — or absent, which
is common on headless/CI hosts. There was no way to ask for a Retina
guest in that case.
Allow an optional "@PPI" pixels-per-inch suffix on --display, e.g.
`--display 3200x1800px@220`. At a Retina-class density the pixel display
then offers a scaling:on (HiDPI) mode. The pixel path never consults
NSScreen, so this works regardless of the host display or whether a user
is logged in on the host.
The hint lives in VMConfig (VMDisplayConfig.ppi) and defaults to the
existing 72 when omitted, so behavior is unchanged for current VMs and
configs. Covered by VMConfigTests (parsing, description round-trip,
effective-PPI default, backward compatibility, malformed input).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Unregister the stdin readabilityHandler when availableData returns empty:
a closed pipe fd stays permanently readable, so Foundation re-invokes the
handler in a tight loop (fstat + zero-byte read) at 100% of one core for
the rest of the command's lifetime.
Fixes#1280
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Publish Tart to openai/homebrew-tools
* Write Tart formula under Formula directory
* Use macOS 26 runners
* docs: install Tart tools from OpenAI tap
* Add required GitHub Actions test check
* Fix hosted tests and notarization credentials
GoReleaser's Homebrew template always emits a bare `depends_on :macos`
for macOS-only formulae. Combining that with the `depends_on :macos =>
:ventura` line injected via custom_block triggers a Homebrew deprecation
warning on `brew upgrade`:
Warning: Calling `depends_on :macos` with `depends_on macos:` is deprecated! Use `depends_on :macos` with `depends_on macos:` inside an `on_macos` block instead.
Please report this issue to the cirruslabs/homebrew-cli tap (not Homebrew/* repositories), or even better, submit a PR to fix it:
/opt/homebrew/Library/Taps/cirruslabs/homebrew-cli/tart.rb:22
Declaring the version constraint inside an `on_macos` block is the form
Homebrew recommends and silences the warning without changing behavior
(still macOS-only, Ventura or newer).
* Use let for the immutable disk image storage attachment
* Don't bind the unused error when catching connection-pool failures
* Report errors thrown inside tart run's fire-and-forget tasks
We were discarding any error thrown inside these unstructured tasks,
which silently hid failures to run the control socket or to start and
stop the VM, and which the compiler now warns about.
Wrap them in an ErrorReportingTask, which spawns the task and reports
any thrown error to stderr, rather than repeating a do/catch at every
call site. An unstructured task spawned from a synchronous context (a
signal handler or SwiftUI action) has no parent to propagate the error
to, so reporting it is the best we can do.
* Avoid blocking SwiftNIO calls in async guest agent connections
The gRPC channel setup in "tart exec" and the MAC address resolver
created a dedicated event loop group and tore both it and the channel
down with the blocking syncShutdownGracefully() and wait(), which are
unavailable from async contexts (the former is an error in the Swift 6
language mode).
Factor the connection out into a withGuestAgentChannel() helper that
uses the process-wide singleton event loop group, so there is no group
to shut down, and closes the channel with the async close().get().
Exposes Apple's macOS 27 guest provisioning API
(VZMacGuestProvisioningOptions) so a macOS guest can be set up
automatically on the first boot after restore.
The flag takes a comma-separated list of key=value pairs mapping 1:1 to
the API properties (fullName, username, password, logsInAutomatically,
enablesRemoteLogin). It is validated to require a macOS 27+ host and a
macOS VM.
The entire user-facing surface is gated behind
'#if arch(arm64) && compiler(>=6.4)' so the flag doesn't appear in help
on toolchains that lack the macOS 27 SDK, while the runtime
'#available(macOS 27, *)' check gates actual use against the host OS.
When built against the macOS 27 (Xcode 27, Swift 6.4) SDK, "tart run"
brings up the VM window but the guest never boots.
Swift's asynchronous main() entry point implicitly starts an executor
that owns the main thread, and as of Swift 6.4 that executor is no
longer backed by the Dispatch main queue. Running an AppKit/SwiftUI
run loop nested inside it via MainApp.main() leaves the main run loop
unable to drain Swift tasks or DispatchQueue.main, so the task that
starts the VM is never scheduled, even though the window itself
(driven directly by AppKit during launch) still appears.
We now keep Root.main() synchronous, so that a command driving a run
loop can own the main thread at the top level, exactly like a plain
SwiftUI app. With AppKit owning the loop again, MainActor tasks and
the Dispatch main queue drain as before. Such commands opt in through
a new MainThreadCommand protocol; everything else keeps running
asynchronously via a detached task and dispatchMain().
Verified that the guest boots again, and that Ctrl+C still stops the
VM gracefully.
* Remove disk v1 support
* fix: address PR review feedback
- add explicit error for legacy disk.v1 media type during pull
- include actionable re-push guidance in runtime error
🤖 Generated with [Codex](https://chatgpt.com/codex)
Co-Authored-By: Codex <codex@openai.com>
* Re-use legacyDiskV1MediaType in error message
---------
Co-authored-by: Codex <codex@openai.com>
Co-authored-by: Nikolay Edigaryev <edigaryev@gmail.com>
Restore the applicationDidFinishLaunching method that was accidentally
removed in commit b1e88e1 ("tart run: do not remove 'Edit' menu as its
not present anymore").
That commit intended to remove the Edit menu removal code (since the
menu no longer exists), but also removed the crucial activation code:
- setActivationPolicy(.regular) - tells macOS this is a GUI app
- activate(ignoringOtherApps:) - brings the window to the foreground
Without these calls, the VM runs fine (SSH works) but no window appears
on screen.
Fixes#1181
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* [docs] publish press release about licensing violation
Highlighting that this is an exceptional case since the company did contact us about a license, and we explicitly declined due to conflict of interests.
* Fixed linting
* Use ghcr.io/cirruslabs/macos-tahoe-base:latest
* CI: "Test on Sequoia" can be named just "Test"
* integration-test: can use latest requests now that the bug is fixed
* Avoid duplicate progress updates in CI logs
* Update Sources/tart/Logging/ProgressObserver.swift
Co-authored-by: Nikolay Edigaryev <edigaryev@gmail.com>
---------
Co-authored-by: Nikolay Edigaryev <edigaryev@gmail.com>
Eugene Petrenko
Fedor Kororkov
Nikolai Tillmann
Greg Hurrell
Tor Arne Vestbø
Nikolay Edigaryev
Fedor Korotkov
sneedandfeed
Eric Kolve
Stefan Mitterrutzner
fsc-eriker