> 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

Enable the seal- prefix on every sealed package the CLI installs in your build.

To rename sealed packages, set the `--use-sealed-names` flag on the Seal CLI. With the flag set, every sealed version 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 version. 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.

## Rewriting the project manifest

Renaming installs every sealed package on disk under its sealed name, but by default your project's own manifest keeps the origin names. On npm that means the root `package.json`, and the dependency references inside `package-lock.json`, still name the origin package. A scanner that reads the manifest therefore reports the same findings as before the fix, or fails outright with "package.json and package-lock.json are probably out of sync".

The `rename-in-manifest` setting closes that gap. It is off by default, requires renaming to be enabled, and requires CLI v0.3.349 or later.

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

Or in `.seal-config.yml`:

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

What it rewrites:

* **npm**: the fixed direct dependencies in the root `package.json` (`dependencies`, `devDependencies`, `optionalDependencies`, and `peerDependencies`), plus every dependency reference in `package-lock.json` that resolves to a fixed package. Lockfile versions 1, 2, and 3 are supported. Reference resolution follows Node's rules, so a nested copy that was not fixed keeps its origin name.
* **Maven**: `pom.xml`, the same rewrite the Maven-only `maven.rename-in-pom` setting already performs. `maven.rename-in-pom` keeps working unchanged.

Setting `rename-in-manifest` without `use-sealed-names` stops the run with the error `rename-in-manifest is only supported when using sealed names`.

Your source code is unaffected: packages stay on disk at `node_modules/<package>`, so imports and `require()` calls need no change.

### npm limitations

* Running `npm install` or `npm ci` after the fix reverts the rewrite, because the public registry serves no `@seal-security` scope. Run `seal fix` and your build in the same CI job, the same model the Maven local cache uses.
* `npm ls` reports the renamed packages as unmet or extraneous. This is cosmetic and does not affect the build or the runtime.
* yarn and pnpm are not covered.

## 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.