brew-cask: Homebrew's cask metadata migration (command_wrapper artifacts, run flight steps) breaks previously-working casks

[bauffman]

Describe the bug

brew-cask: package installs fail hard when the cask uses Homebrew's new structured metadata:

mise ERROR brew-cask:firefox: unsupported artifact type command_wrapper

mise ERROR brew-cask:orbstack: unsupported postflight_steps step type run

This aborts the whole mise bootstrap run, even when the cask is already installed — "latest" re-fetches and re-parses the cask JSON every run, so previously-working configs broke overnight with no config change.

Why this started happening

Homebrew added a command_wrapper cask artifact in Homebrew/brew#23183 (merged 2026-07-21, refined in #23296 / #23308), and started migrating casks in homebrew/cask on 2026-07-29. As of this morning, 62 casks have been migrated to command_wrapper ("<token>: migrate command wrappers.") and 24 casks to structured run flight steps ("<token>: migrate flight commands."), including popular ones like firefox, vlc, obs, orbstack, and the JetBrains IDEs — and the migration appears to be ongoing.

Example — the firefox cask now ships:

{
  "command_wrapper": [
    "firefox",
    { "executable": "$APPDIR/Firefox.app/Contents/MacOS/firefox" }
  ],
  "target": "$HOMEBREW_PREFIX/bin/firefox"
}

and orbstack's postflight is now:

{
  "postflight_steps": [
    { "steps": [
      { "type": "run",
        "command": { "base": "appdir", "path": "OrbStack.app/Contents/MacOS/bin/orbctl" },
        "args": ["_internal", "brew-postflight"] }
    ] }
  ]
}

Where it fails

cask_artifacts() in src/system/packages/brew/cask.rs bails on any artifact type it doesn't recognize, command_wrapper isn't in is_non_install_artifact()'s ignore list, and parse_flight_steps only supports move/remove step types. Per the docs this fail-hard behavior is intentional (no delegation to real brew), so this is a request to support the new metadata rather than a parsing bug.

command_wrapper should be close to the existing binary artifact: instead of symlinking a staged file, brew writes a small wrapper script at target that execs the declared executable (with optional args), so app bundles can expose a CLI without the old symlink-into-app approach.

To Reproduce

# mise.toml
[bootstrap.packages]
"brew-cask:firefox" = "latest"

$ mise bootstrap packages apply
mise ERROR brew-cask:firefox: unsupported artifact type command_wrapper

(or brew-cask:orbstack for the flight-step variant)

Expected behavior

Casks using command_wrapper artifacts and run flight steps install successfully — or at minimum, an unsupported artifact on an already-installed, up-to-date cask doesn't abort the whole bootstrap.

mise doctor output

version: 2026.7.14 macos-arm64 (2026-07-26)

Also checked src/system/packages/brew/cask.rs on current main (post-v2026.7.16): neither metadata type is handled there yet.

Workaround for anyone else hitting this

Move affected casks out of [bootstrap.packages] into a hook using real brew:

[bootstrap.hooks.post-packages]
run = 'test -d /Applications/Firefox.app || brew install --cask firefox'

[jdx]

Thanks for the detailed report and examples. I opened #11472 to add support for both metadata migrations: command_wrapper artifacts (including content/executable forms, args, env, targets, receipt reconciliation, and canonical wrapper staging) and structured run flight steps (bases, templates, guards, env, and sudo handling).

The implementation also preserves runtime variables in literal wrappers and validates command paths and wrapper metadata before installation. The focused cask suite passes with 97 tests, and the repository lint/check workflow passes. The PR is ready for review: #11472

AI-assisted — Tool: Codex; model: OpenAI/GPT-5; version: unavailable.