> 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 three modes the Seal CLI runs in, and which deployment method maps to which 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.
