> 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/seal-os-cicd/seal-fix-os-reference.md).

# seal fix --os reference

`seal fix --os` is the Seal CLI subcommand that seals OS-level packages. It detects which OS-package family the current root filesystem belongs to (`apk`, `deb`, `rpm`), identifies vulnerable installed packages of that family, and replaces them with sealed versions pulled from the matching Seal OS artifact server.

## Synopsis

```bash
seal fix --os --mode <local|remote|all> [other flags]
```

The CLI must run with sufficient privileges to write to the system's package-manager database. Inside a `Dockerfile`'s `RUN` step this is automatic; on a running host this means root.

## Environment variables

| Variable       | Purpose                                                                                                                                                   |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `SEAL_TOKEN`   | The Seal token for authentication. Production tokens for production-equivalent contexts; development tokens for developer machines and feature-branch CI. |
| `SEAL_PROJECT` | The Seal Project ID to attribute the run to. The first run with a value that does not exist creates the project automatically.                            |

These are the same variables `seal fix` uses; one set per build is enough even when application and OS sealing run back to back.

## Flags

`seal fix --os` shares its flag set with `seal fix`: `--mode`, `--silence`, `--skip-sign-checks`, `--summarize`, `--summary-file-path`, plus the persistent `-v` / `--config` / `--clean` / `--remove-cli` flags. Each behaves the same way it does for the manifest target; see the CLI reference chapter for the full list and semantics.

Internal-scanner integrations (Snyk, Black Duck, Ox Security, Checkmarx, GitHub Advanced Security, and JFrog Xray) are not driven by `seal fix --os` flags. When the relevant scanner credentials are present in the CLI's environment or config file, the integration callbacks fire automatically after the seal step; the per-scanner configuration is documented under Integrations.

## OS detection

`seal fix --os` reads the standard distribution-identifying files inside the root filesystem (`/etc/os-release`, `/etc/alpine-release`, `/etc/debian_version`, `/etc/redhat-release`) and dispatches to the matching OS-package family. The dispatch table:

| Detected distribution                                                  | Family | Seal OS artifact server |
| ---------------------------------------------------------------------- | ------ | ----------------------- |
| Alpine Linux                                                           | `apk`  | `apk.sealsecurity.io`   |
| Debian, Ubuntu                                                         | `deb`  | `deb.sealsecurity.io`   |
| Red Hat Enterprise Linux, CentOS, Rocky Linux, AlmaLinux, Amazon Linux | `rpm`  | `rpm.sealsecurity.io`   |

If the detection cannot identify a supported family, the CLI exits with a non-zero status before doing any work. Set the verbosity flag (see the CLI reference) to print the detected files.

## Exit behavior

The command exits with status `0` when it completed: either it replaced one or more vulnerable OS packages with sealed versions, or it found nothing to replace under the active fix mode. A non-zero status means something went wrong, typically one of:

* The token in `SEAL_TOKEN` is missing, malformed, or revoked.
* The CLI cannot reach the Seal Platform or the matching Seal OS artifact server.
* The CLI does not have permission to write to the package-manager database (the build is running as a non-root user that cannot modify `/var/lib/apk` / `/var/lib/dpkg` / `/var/lib/rpm`).
* The detected distribution is not in the table above.

The CLI's stderr output names the specific failure. The first run in a new pipeline benefits from a verbose log capture.

## Related

* [The CLI fix mode](/setup-apps-os/cli-in-cicd/cli-fix-mode.md): how `--mode` maps to the three deployment methods.
* [Sealing OS packages in a Dockerfile](/setup-apps-os/seal-os-cicd/dockerfile.md): the per-distribution `Dockerfile` patterns this reference is for.
* The CLI reference chapter: the global flag reference shared across every `seal` subcommand.