Runtime Support

Purpose and Scope

The Claude SDK for TypeScript is intended for server-side TypeScript or JavaScript applications that call the Claude API. Runtime support therefore matters in two ways: the JavaScript engine must provide the platform features the SDK expects, and the deployment environment must protect Anthropic API credentials. The repository documents a broad set of supported server and edge runtimes, but it also draws a clear safety boundary around browsers and React Native. Use this page when deciding where to run the primary package, how to test it, and which build artifact your tooling should consume.

Sources: README.md, package.json

Runtime compatibility is not a separate package in this repository; it is expressed through the package metadata, TypeScript build configuration, Deno-specific checking configuration, and Jest setup. The published package exposes CommonJS and ECMAScript module entry points from the generated distribution, while the build emits declarations and source maps for TypeScript users. The SDK README is the reader-facing contract for supported environments, and the configuration files show how the maintainers validate and publish that contract.

Sources: README.md, package.json, tsconfig.build.json, tsconfig.deno.json, jest.config.ts

Relevant Source Files

• README.md — states that the SDK targets server-side TypeScript or JavaScript applications and lists supported runtimes, TypeScript requirements, browser behavior, Jest constraints, and React Native status.
• package.json — defines the package name, public entry points, CommonJS package type, import and require exports, TypeScript declaration location, scripts, dependencies, peer dependencies, and browser replacement mappings.
• tsconfig.build.json — configures the generated build from dist/src into dist, including declarations, declaration maps, source maps, and package path aliases.
• tsconfig.deno.json — configures Deno-oriented type checking for dist-deno with es2020 and DOM libraries and no emitted files.
• jest.config.ts — configures the repository test environment as node, maps package imports to source files, and uses SWC for test transforms.

Supported Runtimes

The README lists Node.js 20 LTS or later as the baseline Node environment, with the additional qualifier that supported Node versions should be non-end-of-life releases. It also names Deno version 1.28.0 or higher and Bun 1.0 or later. For edge deployments, the documented targets include Cloudflare Workers, Vercel Edge Runtime, and Nitro version 2.6 or greater. These entries are part of the public support promise for the main SDK package, not just incidental environments where the code may happen to execute.

Sources: README.md

Jest support has a narrower shape than general Node support. The README says Jest 28 or greater is supported only with the node test environment, and explicitly says jsdom is not supported at this time. The repository’s Jest configuration matches that guidance by setting the test environment to node and by mapping package imports directly to source files during tests. This is important for application test suites: if browser-like globals from jsdom are required for other tests, SDK tests or code paths may need a separate Jest project configured for node.

Sources: README.md, jest.config.ts

Browsers are treated as a special case because client-side code can expose secret API credentials. The README says browser support is disabled by default and can be enabled only by explicitly setting the dangerous browser opt-in flag. That wording is intentionally strong: a browser bundle can be inspected by users, extensions, or network tooling, so API keys should normally stay on a server, worker, or trusted backend. The package also contains browser field remappings for selected tool modules, but that package metadata should not be read as blanket permission to ship secret-bearing Claude API calls directly from a public web page.

Sources: README.md, package.json

React Native is not supported at this time according to the README. That limitation should be handled as a planning constraint rather than a runtime error to debug late in development. If a mobile app needs Claude, prefer a backend service that owns the Anthropic credential and exposes an application-specific API to the mobile client. This preserves the SDK’s intended server-side security model while letting the mobile application use Claude-powered features. The README also invites users interested in other runtime environments to open or upvote an issue, which is the appropriate path for unsupported platforms.

Sources: README.md

Build Targets and Module Formats

The package metadata describes how consumers resolve the published SDK. The package name is @anthropic-ai/sdk, the declaration entry is dist/index.d.ts, and the CommonJS main entry is dist/index.js. The package type is commonjs, but the exports map provides both import and require targets: the root package resolves to dist/index.mjs for ESM import and dist/index.js for CommonJS require. The wildcard exports follow the same pattern for generated subpaths, allowing modern bundlers and Node resolution to select the correct artifact based on how the application imports the SDK.

Sources: package.json

The main TypeScript build configuration extends the root TypeScript settings and points at generated source under dist/src. It emits files into dist, enables declaration output, declaration maps, and source maps, and preserves package path aliases for @anthropic-ai/sdk and its subpaths. For SDK users, the practical result is that editor completions, type checking, and source mapping are part of the published build rather than a separate manual setup. For maintainers, this also separates source generation and final package emission into explicit phases.

Sources: tsconfig.build.json, package.json

Deno receives a dedicated TypeScript configuration for dist-deno. That configuration includes the es2020 and DOM libraries, sets noEmit to true, and uses dist-deno as both root and output directory context. The no-emission setting indicates that this file is primarily for checking the Deno-targeted distribution rather than producing the package’s main npm artifacts. The DOM library is significant for Deno and edge-like environments because fetch-style platform APIs are commonly typed through web platform declarations rather than Node-only type packages.

Sources: tsconfig.deno.json

Runtime Selection Guidance

For a typical backend service, start with Node.js 20 LTS or a later non-end-of-life Node release, install the package from npm, and keep the API key in a server-side environment variable. That path aligns with the README example and the package’s default CommonJS and ESM exports. If your service uses ESM, import the default SDK entry; if it uses CommonJS, require the package and let Node choose the require target. In both cases, the package metadata is designed so consumers do not need to import from dist paths directly.

Sources: README.md, package.json

For Deno, Bun, Workers, Vercel Edge Runtime, and Nitro, check the runtime version first and then validate any deployment-specific restrictions such as available environment variables, request streaming behavior, and bundle policy. The repository-level support statement means these environments are intended targets, but edge hosts can differ in how they expose secrets and web APIs. When an edge function calls Claude, treat it like a server: store credentials in the platform’s secret manager, avoid shipping them to clients, and keep direct browser calls disabled unless you have deliberately accepted the documented risk.

Sources: README.md, tsconfig.deno.json

Compact Reference

Area	Repository signal	Practical meaning
TypeScript	TypeScript >= 4.9 in README	Projects should use a compiler version at or above this floor.
Node.js	Node.js 20 LTS or later in README	Prefer current non-EOL Node releases for backend services.
Deno	Deno v1.28.0 or higher plus tsconfig.deno.json	Deno is a supported target with separate type-checking configuration.
Bun	Bun 1.0 or later in README	Bun is a supported JavaScript runtime for the SDK.
Edge	Cloudflare Workers, Vercel Edge Runtime, Nitro v2.6 or greater	Edge-style deployments are supported when secrets remain protected.
Tests	Jest 28 or greater with node environment	Use node, not jsdom, for Jest suites that exercise the SDK.
Browser	Disabled by default, opt in with the dangerous browser flag	Avoid exposing API keys in public client bundles.
React Native	Not supported at this time	Route mobile use cases through a backend service.

Next Steps

After selecting a runtime, read the installation and authentication pages to wire credentials safely, then move to the Messages quickstart to verify the deployment with a real Claude request. If you are configuring tests, mirror the repository’s node-based Jest setup or isolate SDK tests in a node project. If you are targeting edge or Deno deployments, validate the runtime version and secret-storage model before debugging application code, because most runtime issues are caused by platform configuration rather than by differences in the SDK’s public API.