> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/setup-apps-os/cli-in-cicd/cli-fix-mode.md).

# The CLI fix mode

The Seal CLI's fix mode is what the CLI does when it runs against a Seal Project. The mode is set by the `--mode` flag on `seal fix`. There are three values:

| Mode         | What the CLI does                                                                                                                            | Deployment method         |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
| **`local`**  | Reads Sealing Rules from a `.seal-actions.yml` file in the working directory, applies them, replaces matching packages with sealed versions. | **Local**                 |
| **`remote`** | Fetches Sealing Rules from the Seal Platform for the current Seal Project, applies them, replaces matching packages.                         | **Remote**                |
| **`all`**    | Skips the rule lookup entirely. For every vulnerable package the CLI discovers, it replaces it with the sealed version if one exists.        | **Automatic Remediation** |

The mode is the only thing that distinguishes the three CLI-in-CI [deployment methods](/setup-apps-os/choosing-deployment-method.md). The CLI itself, the token, the Seal Project, the network requirements, and the manifest scan are the same.

## Choosing a mode

* Use **`remote`** when Sealing Rules are managed centrally through the Seal Platform UI by a security team.
* Use **`local`** when the Sealing Rules should live alongside the code they apply to, version-controlled with it, and reviewed in the same pull requests as code changes. The [Seal GitHub App](/discovering/connecting-source-control/github.md#automatic-pull-requests) can open automatic pull requests that populate `.seal-actions.yml` for you.
* Use **`all`** when the team wants every vulnerable package replaced as a matter of policy, with no per-rule review. This produces the most replacements with the least operational effort, at the cost of the per-rule control the other two modes provide.

The recommended ordering for the three is in [Choosing your deployment method](/setup-apps-os/choosing-deployment-method.md#recommended-ordering).

## What the mode controls

The fix mode determines which packages the CLI replaces on a given run. In `remote` mode, the CLI applies the remote Sealing Rules attached to the Seal Project; in `local` mode, the rules in `.seal-actions.yml`; in `all` mode, every vulnerable package that has a sealed version.

The Seal Project's current fix mode is visible on the [Projects page](/getting-started/creating-a-seal-project.md#editing-a-project), recorded from the most recent CLI run.

Switching modes is supported in any direction, but be aware that a run in the new mode no longer applies the rules from the previous one. Switching from `remote` to `local` makes your existing remote Sealing Rules effectively inert; switching from `local` to `remote` does the same for the rules in `.seal-actions.yml`. Pick a mode, recreate the rules in the new location if you change your mind, and stick with it. See [Mode changes in Creating a Seal Project](/getting-started/creating-a-seal-project.md#mode-changes).

## Related

* [Choosing your deployment method](/setup-apps-os/choosing-deployment-method.md): the decision page that places the three modes within the broader five-method picture.
* [Sealing Rules](/using-platform/sealing-rules.md): what `local` and `remote` modes apply, and how they are created.