Client runtime reference
Every connected Cheetah client uses the shared TypeScript core, but a useful runtime is more than a transport. It combines stable identity, one execution lifetime, action registration, local authority, result publication, state reporting, and the adapters that can actually touch a browser, machine, page, or native host.
The shared core preserves one command and evidence model. Platform compositions decide where identity survives, which resources can be addressed, and which authority the runtime can exercise.
Choose the highest-level suitable factory
| Environment | Factory | Use it when |
|---|---|---|
| new or specialized platform | createCoreRuntime() | you can provide the transport, identity, response, lifecycle, and platform handlers deliberately |
| Chrome MV3 extension | createBrowserRuntime() | a service worker coordinates tabs, windows, content scripts, capture, and parser support |
| Node or machine agent | createConsoleRuntime() | the client needs file-backed identity, logical flows, and optional filesystem, shell, or download actions |
| cooperative page | createWebRuntime() | code running in one page may expose that page's DOM without extension authority |
| embedded JavaScript/native host | createMobileRuntime() | native code supplies WebSocket, HTTP, identity, and handler bridge functions |
The specialized factories are compositions over core rather than independent protocols. They inherit core validation, local policy, approval, leases, cancellation, response shape, handshake, reconnection, and telemetry behavior, then add platform-specific providers and actions.
Runtime identity has two lifetimes
A stored client_id is the stable logical address. An instance_id belongs to one runtime construction. Transport reconnection keeps both IDs and repeats the handshake. Rebuilding a destroyed service worker or process normally restores the client ID and creates a new instance ID, allowing the server to fence old work from its replacement.
The default core identity is ephemeral and therefore unsuitable when the product expects a logical client to survive reconstruction. Browser, console, web, and mobile compositions each provide a platform-specific identity mechanism with different durability and security properties.
Composition does not grant platform authority
An advertised handler says that executable code was registered before startup. It does not prove that Chrome granted a permission, an operating-system account may read a path, a page origin may access a resource, or a native bridge actually implemented a capability. Local policy can narrow the platform's authority; it cannot create authority the platform does not have.
The following pages document the factories at the level needed to build and operate them:
- Shared core runtime for the common lifecycle and extension seams;
- Browser-extension runtime for Chrome MV3 composition;
- Console runtime for Node and machine clients;
- Web and mobile runtimes for cooperative pages and native bridges.