hashicorp/vagrant · warning

feature will stop working in the next version.

Error message

feature will stop working in the next version.

What it means

Third and final line of the hardcoded deprecation warning in `vagrant box remove` (remove.rb:62): 'feature will stop working in the next version.' Printed after the other two lines when the command receives two positional arguments; execution then continues with options[:provider] set from argv[1], so today the removal still happens.

Source

Thrown at plugins/commands/box/command/remove.rb:62

            o.on("--all-architectures", "Remove all architectures within a provider a version of the box") do |a|
              options[:all_architectures] = a
            end
          end

          # Parse the options
          argv = parse_options(opts)
          return if !argv
          if argv.empty? || argv.length > 2
            raise Vagrant::Errors::CLIInvalidUsage,
              help: opts.help.chomp
          end

          if argv.length == 2
            # @deprecated
            @env.ui.warn("WARNING: The second argument to `vagrant box remove`")
            @env.ui.warn("is deprecated. Please use the --provider flag. This")
            @env.ui.warn("feature will stop working in the next version.")
            options[:provider] = argv[1]
          end

          @env.action_runner.run(Vagrant::Action.action_box_remove, {
            box_name:     argv[0],
            box_architecture: options[:architecture],
            box_provider: options[:provider],
            box_version:  options[:version],
            force_confirm_box_remove: options[:force],
            box_remove_all_versions: options[:all],
            box_remove_all_providers: options[:all_providers],
            box_remove_all_architectures: options[:all_architectures]
          })

          # Success, exit status 0
          0
        end
      end

View on GitHub (pinned to 35f3160f4a)

Solutions

  1. Migrate now to `vagrant box remove <name> --provider <provider>`.
  2. Add a lint step or pre-flight check in automation that fails if it detects the two-argument form, so the breakage surfaces before the upgrade.
  3. Re-test all box-removal scripts after each Vagrant upgrade, since the removal of this feature lands silently in release notes.

Example fix

# before
vagrant box remove hashicorp/bionic64 virtualbox

# after
vagrant box remove hashicorp/bionic64 --provider virtualbox
Defensive patterns

Strategy: validation

Validate before calling

# fail fast in automation if the to-be-removed form is detected
if [[ "$*" =~ ^box\ remove\ [^ ]+\ [^ ]+$ ]]; then
  echo "legacy positional provider will break next version" >&2; exit 2
fi

Prevention

When it happens

Trigger: `vagrant box remove <box-name> <provider>` (two positional args) on current Vagrant; will become a hard usage error (CLIInvalidUsage path / ignored extra arg) once the deprecated form is removed in the next version.

Common situations: Users who keep using the old form and treat the warning as noise will find their scripts breaking at the next major upgrade; the 'next version' deadline makes this a time-bomb for unattended automation.

Related errors


AI-assisted analysis of hashicorp/vagrant@35f3160f4a (2026-08-21). Data as JSON: /api/errors/83babd3926a4756c. Report an issue: GitHub.