@cloudflare/sandbox@0.7.20 does not export concrete error classes like SessionAlreadyExistsError / SessionDestroyedError / ProcessNotFoundError #517

Summary

The published @cloudflare/sandbox@0.7.20 package does not export several concrete error classes that appear to exist in the source tree, including:

• SessionAlreadyExistsError
• SessionDestroyedError
• ProcessNotFoundError
• possibly SandboxError as well

This makes it hard for consumers to do exact error handling and forces them to fall back to checking error.name / error.code strings.

Version

• @cloudflare/sandbox: 0.7.20

Repro

import {
  SessionAlreadyExistsError,
  SessionDestroyedError,
  ProcessNotFoundError,
} from "@cloudflare/sandbox";

TypeScript reports:

Module '"@cloudflare/sandbox"' has no exported member 'SessionAlreadyExistsError'.

What I observed

In the source tree for tag 0.7.20, these classes exist:

• packages/sandbox/src/errors/classes.ts
• packages/sandbox/src/errors/index.ts

But the root package entrypoint does not appear to re-export them:

• packages/sandbox/src/index.ts

In the published package:

• the built code appears to contain the classes internally
• but the package entrypoint does not expose them as public exports
• dist/index.d.ts also does not expose them

Expected

One of:

1. These concrete error classes are exported from @cloudflare/sandbox, so consumers can do:

if (error instanceof SessionAlreadyExistsError) {
  ...
}

2. Or, if these are intentionally internal, the package/docs should make that explicit and recommend the supported public matching strategy.

Actual

So in practice, consumers end up doing fallback checks like:

if (error instanceof Error && error.message.startsWith("SessionAlreadyExistsError:")) {
  // handle duplicate named session
}

or checking error.name / error.code if present.

Why this matters

A common use case is handling sandbox/session lifecycle errors exactly, for example:

• named session already exists
• session destroyed during cleanup
• process not found during log lookup

Those are much safer to handle with exact exported classes than with string comparisons.

Requested fix

One of these would solve the issue cleanly:

1. Re-export the concrete error classes from @cloudflare/sandbox, so consumers can use instanceof.
2. If these are intentionally not part of the public API, document the supported matching contract explicitly, for example:
   • error.name
   • error.code
   • which values are stable and supported
3. Alternatively, expose stable type guards/helpers from the public package, for example:
   • isSessionAlreadyExistsError(error)
   • isSessionDestroyedError(error)
   • isProcessNotFoundError(error)