continuedev/continue · error · Error

Slug-based package resolution is not supported

Error message

Slug-based package resolution is not supported

What it means

RegistryClient.getContent only supports file-based identifiers. A slug-based PackageIdentifier (owner/package) cannot be resolved because no registry backend is wired up, so it throws explicitly.

Source

Thrown at packages/config-yaml/src/registryClient.ts:27

export class RegistryClient implements Registry {
  private readonly rootPath?: string;

  constructor(options: RegistryClientOptions = {}) {
    this.rootPath = options.rootPath;
  }

  async getContent(id: PackageIdentifier): Promise<string> {
    // Return pre-read content if available (for vscode-remote:// URIs in WSL)
    if (id.uriType === "file" && id.content !== undefined) {
      return id.content;
    }

    switch (id.uriType) {
      case "file":
        return this.getContentFromFilePath(id.fileUri);
      case "slug":
        throw new Error("Slug-based package resolution is not supported");
      default:
        throw new Error(
          `Unknown package identifier type: ${(id as any).uriType}`,
        );
    }
  }

  private getContentFromFilePath(filepath: string): string {
    if (filepath.startsWith("file://")) {
      // For Windows file:///C:/path/to/file, we need to handle it properly
      // On other systems, we might have file:///path/to/file
      return fs.readFileSync(new URL(filepath), "utf8");
    } else if (path.isAbsolute(filepath)) {
      return fs.readFileSync(filepath, "utf8");
    } else {
      // Try to resolve relative to current working directory first
      const resolvedPath = path.resolve(filepath);
      if (fs.existsSync(resolvedPath)) {

View on GitHub (pinned to 5522c6f44c)

Solutions

1. Convert the identifier to a file URI ({uriType:'file', fileUri:'./path'}) pointing at the block's YAML file
2. Or use a registry implementation that supports slug resolution
3. Check whether your package version expects a different registry client for slug lookups

Example fix

// before
registry.getContent({ uriType: 'slug', fullSlug: { ownerSlug: 'o', packageSlug: 'p' } });
// after
registry.getContent({ uriType: 'file', fileUri: './blocks/p.yaml' });

if (id.uriType === 'slug') { /* resolve via a slug-capable registry or convert to file */ }

function isFileIdentifier(id: PackageIdentifier): id is { uriType: 'file'; fileUri: string } {
  return id.uriType === 'file' && typeof (id as any).fileUri === 'string';
}

try { await registry.getContent(id); } catch (e) { if (e.message === 'Slug-based package resolution is not supported') { /* fall back to file resolution */ } }

When it happens

Trigger: new RegistryClient(...).getContent({uriType: 'slug', fullSlug: {...}}) — any slug identifier.

Common situations: Code written against a full registry assuming remote slug resolution, but running with the local file-only registry client; config blocks referencing slugs instead of file paths.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• '${modelName}' not found in the Ollama registry!
• Unknown URI type: ${(identifier as any).uriType}
• Invalid FQSN format: package slug must have two parts
• Block ${packageIdentifierToShorthandSlug(id)} not found
• Invalid MCP tool reference "${toolRef}": colon-separated too

AI-assisted analysis of continuedev/continue@5522c6f44c (2026-08-27). Data as JSON: /api/errors/89bf384535943536. Report an issue: GitHub.