> 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/integrations/package-renaming/renaming-sealed.md).

# Renaming sealed packages

To rename sealed packages, set the `--use-sealed-names` flag on the Seal CLI. With the flag set, every sealed iteration the CLI installs in this run goes onto disk under a `seal-` prefixed name.

## How to enable it

Three equivalent paths. Pick whichever fits your CI configuration:

### CLI flag

```bash
seal fix --mode=remote --use-sealed-names
```

(`--mode=local` or `--mode=all` work the same way; the flag is independent of the fix mode.)

### Environment variable

```bash
SEAL_USE_SEALED_NAMES=true
seal fix --mode=remote
```

### `.seal-config.yml`

```yaml
project: <seal project id>
use-sealed-names: true
```

The setting is per Seal CLI invocation; it applies to every sealed package the CLI installs during that run.

## What stays the same

Code that imports, requires, or otherwise references the package by its original name continues to resolve to the sealed iteration. The CLI handles whatever per-ecosystem plumbing is needed so the build behaves identically to a build against the original name.

This is what makes renaming a usable default: the scanner sees a name it does not recognize, but everything downstream of the package manager sees the package it expects.

The exact naming pattern is ecosystem-specific. See [Naming and versioning conventions](/reference/naming-and-versioning/renamed-packages.md) for the canonical reference.

## Java: class-file fingerprinting scanners

Renaming changes what a scanner reads in the manifest, which is enough for scanners that match on package name and version. Some scanners instead fingerprint a JAR by the contents of its `.class` files, and continue to identify the sealed JAR as the origin package version even after its coordinates are renamed — reporting the origin version's vulnerabilities on the sealed build.

For the Java ecosystems (Maven, Gradle, and loose Java files), the `update-class-metadata` toggle avoids these false positives. It is off by default and only takes effect when renaming is enabled. See [Environment variables](/reference/cli/environment-variables.md) for the per-ecosystem toggles.

## Related

* [Naming and versioning conventions: Renamed packages](/reference/naming-and-versioning/renamed-packages.md): the per-ecosystem naming pattern.
* [Renaming non-vulnerable packages that trigger false positives](/integrations/package-renaming/renaming-non-vulnerable.md): the per-package alternative for one-off cases.